Wikipedia:Village pump (policy)/Archive 183

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (policy) archive  

This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196

RfC: Delete all webcitation.org links

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Keep. RfC proposal invalidated by WebCite itself, which came back online while the RfC was ongoing. The WebCite outage lasted about 1.5 years. Further discussion about WebCite at Talk:WebCite GreenC 18:01, 24 June 2023 (UTC)

---

This is a continuation of the previous RfC three years ago that passed to deprecate WebCite. The proposal today is to delete all remaining WebCite links. -- GreenC 17:46, 22 May 2023 (UTC)

As background, WebCite archives became unavailable over a year ago. Attempts were made by The Internet Archive to work with the owner of WebCite to transfer the content to Internet Archive, but no agreement was reached due to the owner's insistence on being paid a significant amount of money. Other entities also tried to work with the owner to no avail, his evident position was/is either pay up, or let it burn. The WebCite software is outdated and convoluted and the technician who was able to keep it going left the company. It's unclear even we had the data it might be non-trivial to move to another provider due to how it was built with frames to prevent transferring of the archive pages. The owner ran WebCite as a side project, there are no indications it is coming back online.

• Bots have already moved to other providers. The remaining WebCite links have no known archives elsewhere.

The proposal would allow for bots to automate deletion of links with the end goal of having none left. The exact procedure for deletion is still be worked out since the links exist in different formats and in various ways (CS1|2 templates, {{webarchive}}, square and bare links, {{official}}, etc...). The underlying source URL would be preserved where possible. -- GreenC 17:46, 22 May 2023 (UTC)

Survey (delete webcitation.org links)

• Delete per/as nom. -- GreenC 17:46, 22 May 2023 (UTC)
• Keep -- I have severe concerns when a disclosed paid agent of the Internet Archive is telling us that because the IA itself was unwilling to pay the price for the resource, all links to it should be removed. Having been told that the resource has been made available for purchase, we should be open to the thought that some other player may choose to purchase it, at which point the absence of those links becomes a matter of devaluing both the resource and Wikipedia. At the very least, we should not be deleting the record of a webcite where we do not have the original underlying URL, as the webcite is our record that there was something, somewhere being cited. --Nat Gertler (talk) 20:15, 22 May 2023 (UTC)
• Keep per NatGertler, who said everything I would have but more concisely. This proposal is too soon, and too mired in IA's own organizational politics. Agree with AquilaFasciata under "Discussions" below that when possible a WebCite link should be replaced with a working IA (or other) one.  — SMcCandlish ☏ ¢ 😼  22:04, 22 May 2023 (UTC)
• Remove eventually per nom, but it seems like the devil is in the details as to what an automated removal/replacement process could look like. -- Visviva (talk) 22:18, 22 May 2023 (UTC)
• Keep until the details of how the removal will be effected and what they will be replaced by are agreed. There should be some way for humans to identify that there used to be a webcition.org in an article and what it was, and some way to easily find these articles. Deletion without replacement or replacement with a {{citation needed}} or similar template will lead to the loss of probably-verifiable information because it is uncited. Thryduulf (talk) 02:19, 23 May 2023 (UTC)
• Close as premature, because of the discussion immediately below this one.—S Marshall T/C 08:42, 23 May 2023 (UTC)
• RfC unnecessary as if a link becomes dead we immediately work to find the archived link. If there is a need for an RfC, then I concur with replacing the broken archive links with archive links that actually work, and if that means using Internet Archive, that's that. Aasim - Herrscher of Wikis ❄️ 13:36, 23 May 2023 (UTC)
• Delete: Links to WebCite have been dead since October 2021. Any WebCite URLs that are used in citations in our articles, and whose original source is unavailable or deviated, are not serving any purpose towards WP:V. Removing any remaining links to WebCite that were missed in earlier runs of GreenC's bot, along with tagging with {{dead link}} will allow IABot to attempt a fix. Yes it is possible that no archival copy of those citations exist on other archive platforms, but this will at least fully reveal the scale of that problem which already exists (because WebCite links are already broken anyway).
  Is it possible that WebCite could still be bought and somehow restored at the same URL? Or restored at a different URL? Sure, maybe. And if that happens, and the citations aren't covered by another archival service, that's something that can be solved either by restoring the URL from the article history, or a bot who can re-add the URL in whatever format the revived service uses. Sideswipe9th (talk) 13:52, 23 May 2023 (UTC)
• Delete. Keeping these broken links doesn't fix anything and just stands in the way of actually seeing the full scope of the issue. A dead archive is a dead link, and it should be tagged as such. If we need to know when a website was accessed, then that's exactly what the |access-date= parameter would be for. –MJL ‐Talk‐^☖ 03:04, 24 May 2023 (UTC)
• Keep as per SMcCandlish. Instead of deletion, could we tag these references so that people who do want to replace these links or find other archives can do so? - AquilaFasciata (talk | contribs) 13:15, 24 May 2023 (UTC)
• Keep per NatGertler, SMcCandlish, et. al. --Jayron32 16:54, 24 May 2023 (UTC)
• Keep, but tagging en masse may be appropriate. As I understand it, all of these links are dead and the only archive was held by WebCite. I don't see how one dead link is better than two. These are difficult cases of link rot that may require finding new references or removing information—this suggestion doesn't aid this manual task. — Bilorv (talk) 15:45, 30 May 2023 (UTC)
• Keep on the understanding these links are only still included in Wikipedia articles where the original link is dead and no other archive service has the content. I don't think removing the link is an improvement in that narrow circumstance. (at least not yet) Walt Yoder (talk) 19:23, 31 May 2023 (UTC)
• Delete My understanding, unlike my understanding of some of what the keep !votes are arguing, is we're just deleting completely dead links, not anything more. If I'm not mistaken, this should be done post-haste. SportingFlyer T·C 18:04, 6 June 2023 (UTC)
• Delete I wonder if anyone has entertained the possibility of the domain being taken over by a rogue operator and redirecting traffic to shady sites or other not related sites. It is a lucrative domain for any black-hat SEO people to take over. The current module do not seem to have protection from archive urls getting usurped. – robertsky (talk) 03:20, 9 June 2023 (UTC)
• Delete. GreenC, as a longtime volunteer in this area (that's how he got hired by IA), is the right person to make the suggestion he has. But besides that, we are not served whatsoever by dead archive links. They are literally the most useless links we could have.

  Simply deleting the link and setting |url-status=dead is sufficient to identify in a citation that the citation is malformed and needs repair by emitting a maintenance message (see also Category:CS1 maintenance): "Google".{{cite web}}: CS1 maint: url-status (link). I think that would be a blunter instrument than preferred for this case, and would probably prefer to see the archive URL removed and |url-status= set to some other keyword (we already have bot: unknown, bot: webcitation may be appropriate). Of course, in some cases the URLs are in a separate template entirely due to use with a "manual" citation, which probably merit removal entirely with the addition of {{dead link}}. Izno (talk) 19:49, 13 June 2023 (UTC)

Discussions (delete webcitation.org links)

• Is there any idea how many citations are only available on WebCite vs. how many are available through alternative archives? Would it be possible to move those to alternative platforms? - AquilaFasciata (talk | contribs) 19:23, 22 May 2023 (UTC)
• I was just going to ask the same question that AquilaFasciata asked. Also, what is more "preserving" of the current link than the status quo? Or, to combine the questions, can a bot try to link somewhere newer, and, when not possible, leave it in place as with any other completely dead link? Actually not surely permanently dead per NatGertler|'s post. North8000 (talk) 20:33, 22 May 2023 (UTC)

  It's in the 10s of thousands I don't have an exact count. Bots have already moved everything that can be moved. Whatever is left doesn't exist elsewhere. -- GreenC 22:04, 22 May 2023 (UTC)

  Using this naive search I get a little over 20k occurrences of "webcitation.org" in article space. But the couple that I've looked at (e.g. this one on Clint Eastwood) seem to be replaceable with IA archives. But it seems like they might require a human in the loop to verify that the new archive, which will generally be from a different day, actually still supports the cited assertion. -- Visviva (talk) 22:16, 22 May 2023 (UTC)

  That should have been converted by my bot on June 14, 2022 but the {{cite web}} template contains {{'-}} which is either an old bug fixed or an unidentified bug that threw off the parser. When the WebCite link is removed, it will add a {{dead link}}, then IABot will add any available archive URL. It shows how these WebCite links are gumming things up. -- GreenC 01:26, 23 May 2023 (UTC)

  National Front (UK) election results has links with titles that imply they are from webcitation.org but actually link to pages on the Internet Archive. This appears to be because GreenC bot changed the archives but left the titles alone, I haven't investigated how common this is, nor whether it is something that a bot could reliably fix, but if it is common it will distort the scale of the problem (because while the titles are a problem, it is a different, lesser one). Thryduulf (talk) 02:53, 23 May 2023 (UTC)

  @GreenC: looking through the raw list I found Kit Hinrichs, where almost all of the external links used just www not http://www which seems to have mean it wasn't spotted by whatever process you used to find webcitation.org links. I fixed this issue and ran the normal fix dead links tool on the article, but all it did was mark the webcitation.org links as dead (even though the main URLs are also no longer working in at least some cases). Please could you recheck that article for working archives on other services and any others that might have the same issue. Thryduulf (talk) 21:11, 28 May 2023 (UTC)

• Responding to Nat Gertler's concerns, I was not asked by IA to do this work, it's my own initiative as a Wikipedia editor for the past 20 years, this has nothing to do with IA. IA has no interest if these links are kept or deleted. The idea that WebCite will sell the content to be made live again is laughable for a couple reasons some of which I touched on in the nom. IA offered to pay for reasonable expenses, such as for the hardware and shipping and time to prepare it all, but WebCite wants to make a lot of money from it. Since no one bit, and a few entities tried, the owner of WebCite walked away from it burning the open source community and community of archive providers who usually work together (this all happened over a year ago). I am paid by IA but also work with other archive providers towards the common goal of saving dead links (Special:Diff/1155651594/1156379648). The idea that someone else might pay for it in the future is extremely unlikely. I suppose Wikipedia can hold out hope, but the cost is 10s of thousands of inoperable archive links that are non-verifiable cluttering the system wasting people's time. -- GreenC 22:04, 22 May 2023 (UTC)
• Comment If the citations still exist, albeit just inaccessible barring a commercial arrangement, wouldn't deleting them all leaving content unsourced be inconsistent with WP:SOURCEACCESS? Betty Logan (talk) 02:25, 23 May 2023 (UTC)

  The proposal is to delete dead WebCite links, not citations. -- GreenC 03:32, 23 May 2023 (UTC)

  Yes, but if Webcite is the only resource where they exist then deleting them will render them irretrievable. While there is a clear advantage to replacing this links if possible, I don't see what the upside is to deleting them. There is a clear downside if the licensing issue is resolved and Wikipedia has deleted the links. Betty Logan (talk) 06:04, 23 May 2023 (UTC)

  The WebCite URLs are already dead. They functionally serve no purpose towards WP:V, because clicking on them doesn't actually bring you to an archived copy of whatever the citation is supposed to be. The SOURCEACCESS problem already exists.

  There is a clear downside if the licensing issue is resolved and Wikipedia has deleted the links. There's two solutions to this. Deleting the WebCite links doesn't actually remove the link itself from the article history. If the service does somehow become live again at the same URL and with the same URL pattern as previously, those links can be easily retrieved from the article history. However, if the service does become live again, either at the same URL or a different one, it is I think reasonable to assume so will its APIs. If that is the case, then bots like IABot can use those APIs to query for archived copies of a given URL in the same manner as they did previously to the site going offline in October 2021, and automatically restore/re-add the archived URLs. Sideswipe9th (talk) 14:04, 23 May 2023 (UTC)

• Comment: Examples Some examples of what would happen:

Type 1: CS1|2:

Source: {{cite web |url=http://example.com |archive-url=https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/ |archive-date=2000-01-01 |title=Example}}

Result: {{cite web |url=http://example.com |title=Example}}{{dead link}}

Type 2: Square-url:

Source: [https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/ Example]

Result: [http://www.example.com/ Example] {{dead link}}

Type 3: Square-URL with {{webarchive}}:

Source: [http://www.example.com/ Example] {{webarchive |url=https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/}}

Result: [http://www.example.com/ Example] {{dead link}}

Type 4: Bare-url:

Source: * https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/

Result: * http://www.example.com/ {{dead link}}

• Note 1: The above should be at least 80% of them. The remaining may not have a ?url= (such as "https://www.webcitation.org/5eWaHRbn4" only) in which case they will be removed when Type 1 or 3, and kept elsewhere for manual review.
• Note 2: In terms of logging that is easily done with a CSV on wiki, containing 1 line per citation, with the first column page title, second column the unmodified citation (newline converted to "__newline__"), third column the replacement citation, and fourth column the WebCite URL. In this way the entire thing is easily reversible on a per page or entire site basis.

-- GreenC 05:16, 23 May 2023 (UTC)

Why is there an assumption that the original source url is a deadlink? — xaosflux ^Talk 14:58, 23 May 2023 (UTC)

Well this is the case in all of the above "Source" examples (except for Type 3). They were originally treated as dead so nothing changes. For Type 3 it can do a status check and not mark as dead if it's 200; this is a problem for soft-404s in which case running IABot on the pages post-processing will weed some of those out. -- GreenC 15:09, 23 May 2023 (UTC)

@GreenC sorry I'm missing something, say we have this source: https://www.webcitation.org/6YloKPaFj?url=https://www.princeton.edu/mudd/news/faq/topics/Non-Cooperative_Games_Nash.pdf Example; and we convert it to https://www.princeton.edu/mudd/news/faq/topics/Non-Cooperative_Games_Nash.pdf Example -- why would {{dead link}} be appended if the link isn't actually dead (in this example the link is not actually dead)? While the webcitation link is dead, this would actually revive the link and make it no longer dead. — xaosflux ^Talk 13:24, 24 May 2023 (UTC)

Are you suggesting that a bot re-test whether the original link is dead, since some of them may have been incorrectly marked as dead when they weren't? WhatamIdoing (talk) 23:54, 24 May 2023 (UTC)

He's suggesting a very edge case scenario. And if it happened, while a problem remains, it's a less severe problem then before. At least now we have a working live link, whereas before it was a dead archive link. It's a step in the right direction. -- GreenC 20:17, 25 May 2023 (UTC)

I'm asking what the tolerance is for making a bad edit unnecessarily. If someone is going to go out of their way to insert a warning notice, we would normally expect this to be accurate. If this is all going to be handled by a bot, the bot could do live checking no? — xaosflux ^Talk 19:07, 31 May 2023 (UTC)

If the site is completely gone, then it's easy to check, but if it's still there and has been re-organized, or taken over by a squatter, then it's an AI problem for a bot to figure out if the current link target matches the intended target. Many common cases could probably be dealt with by heuristics, but I suspect there would still be a lot of pages that wouldn't be handled by simple rules. isaacl (talk) 21:14, 31 May 2023 (UTC)

@Thryduulf and Visviva: pinging re: implementation details posted above. -- GreenC 05:22, 23 May 2023 (UTC)

I don't have time right now for more than a quick response, but while that's better than nothing it doesn't do anything to indicate that it was formerly a webcitation.org url so editors could waste time searching in other archive sites even though we know that the URIs aren't there. I don't understand your CSV comment. Thryduulf (talk) 09:22, 23 May 2023 (UTC)

@Thryduulf, the CSV comment suggests essentially that we should keep a record of the changes made. — Qwerfjkltalk 10:31, 23 May 2023 (UTC)

I don't see how keeping the webcitation link solves your problem. Users will still be wasting time trying to find a replacement for the webcitation link. But this problem is universal to any link marked {{dead link}}, users will waste time trying to find replacements. This is why we have archive bots that do this automatically. There are over 20 archive providers. -- GreenC 14:56, 23 May 2023 (UTC)

Unless there could be something useful in the archive's URL itself (last date it was active?), maybe the archive's URL should be removed and replaced with a note that a bot has attempted and failed to find an archive of the webpage. WhatamIdoing (talk) 03:39, 1 June 2023 (UTC)

FWIW, this sounds OK to me, and I definitely support keeping an on-wiki CSV (or similar) log of the changes. -- Visviva (talk) 03:05, 28 May 2023 (UTC)

In "type 1", why would we do {{cite web |url=http://example.com |title=Example}}{{dead link}} instead of {{cite web |url=http://example.com |title=Example |url-status=dead}}?  — SMcCandlish ☏ ¢ 😼  17:58, 16 June 2023 (UTC)

When you set |url-status=dead without also setting |archive-url=, the CS1/2 templates output a maintenance error, and adds the article to the tracking Category:CS1 maint: url-status. Sideswipe9th (talk) 18:48, 16 June 2023 (UTC)

Keep Insofar as I can tell, existing webcitation.org links are currently working. Sofashop (talk) 04:32, 24 June 2023 (UTC)

Well well. After a year and half outage, it came back online concurrent with this RfC. I'm glad to see, because while Enwiki only has about 30k links, Wikipedia as a whole across languages and projects has more than 2 million. Even if this RfC has passed with support and the links removed, it would have been trivial to re-add them so no damage would have been done. At this point I think the RfC can be closed as invalid. -- GreenC 17:51, 24 June 2023 (UTC)

It might be worthwhile to use this opportunity to backup the now accessible archives to another service, so that if WebCite goes down again we at least have alternatives to substitute in. Is this something that could be automated? Sideswipe9th (talk) 17:57, 24 June 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC at WP:Notability (geographical features)

You are invited to the discussion at WP:Notability (geographical features) an RfC regarding proposal of adding Administrative divisions to WP:GEOLAND.Davidstewartharvey (talk) 11:33, 27 June 2023 (UTC)

The permissibility of large tables of primary-sourced technical information, and other similar content

I've noticed two hotly-contested articles where people have been arguing bitterly about whether or not to keep large tables of information on computer hardware sourced from the manufacturer, Exmor and iOS version history. I've also noticed more nascent or potential conflict in this vein brewing on some other similar hardware article talk pages, such as List of Nvidia graphics processing units and ISOCELL, and I wouldn't be surprised if there's more elsewhere. It seems to have started sometime around last November, and it may just continue to grow, because the arguments many people have made in favor of removing the tables could apply to similar tables and lists on many articles. Those arguments, which in policy terms rest more-or-less on a combination of WP:NOTCATALOG and WP:PRIMARY I think, do not seem to convince many other editors who are attached to the tables (as well as many readers who jump in as IPs or make an account just to argue for the tables being kept). The editors in favor of the tables don't seem to make policy-based arguments like that for their side as much, but they don't at all seem convinced that policy is on the side of their opponents.

I'm not really invested in either side. Rather, I just think it would be nicer for everyone involved if the policy was more clear, so it's not such a potent source of conflict. Many of those tables have been on Wikipedia and continuously maintained for over a decade; if we're going to start saying that their contents absolutely need to be sourced from secondary sources and well-integrated into the flow of the article text and so on, and otherwise they need to go, that does seem sort of like a new status quo in practical terms that could upend many articles, and it would be worth establishing that unambiguously if that is really what people want.

As things currently stand, the main argument I could really see against the tables from WP:NOTCATALOG is the "simple listing" clause, and it strikes me as very much a matter of opinion what constitutes proper "contextual information" that would justify the presence of one of those tables. You could maybe also argue from its WP:NOTPRICE clause but these kinds of tables don't include price information and aren't necessarily for conducting business per se. So, I think if people want to use WP:NOTCATALOG as a basis to remove the tables, it should probably be worded less ambiguously to that effect—perhaps removing them is in the spirit of WP:NOTCATALOG(?) but the language leaves plenty of room for counterargument. As far as WP:PRIMARY goes, I think you could make the argument that as long as the article the table is embedded within is based mainly on secondary sources and passes the notability threshold, WP:NLIST could possibly give the table a pass. So, overall, it doesn't exactly seem to me like an open-and-shut case in policy terms that the tables just don't belong, at least in terms of existing policy. That's not to say that I think the arguments against them are wrong necessarily, just that I don't think existing policy is so clear as to leave no room for doubt—in trying to figure it out I've just been left feeling kind of confused.

(Of course, people also make lots of arguments on both sides that aren't really based in policy—often that the tables take up too much space in page layout or data terms, aren't encyclopedic, and could go elsewhere on the Web on the one hand, and that the tables are useful, unique, and the product of years of work on the other hand. I'm not sure if there's any good way to weigh these sorts of arguments against each other as they're rather at cross-purposes.)

So, if there's an article that is well-sourced and clearly notable and so on, and it has a large table based on primary sources like manufacturer documentation, assuming the overall subject of the table is covered in secondary sources and its contents aren't copyvio, should it stay or go, if it's possible to state a general guideline? Does it matter if the table stands apart from the rest of the article? Does anything change if the table is so huge that half the bytes of the article are just given over to the table, or if the article has little text and consists mostly of giant tables? All of these things and more have been the subject of controversy and it doesn't seem like either side really has a devastating argument to make right now that the other side will accept, so I worry that if we can't clarify the policy somehow overall, every large primary-sourced table across the encyclopedia will be fought over one-by-one in the months and years to come. Mesocarp (talk) 22:08, 15 June 2023 (UTC)

Thats a rather long text to read. But I also noticed that tables were and are an issue lately. Specially if tables should be sourced or not was the issue there. Eventually the party who demanded a sourced table won, but there was a discussion about if tables should be sourced or not. Also in the recent ITN discussion on the posting of the Stanley Cup Finals this was an isssue. The it was sourced with NHL, but I saw the source as used in good faith and the article had a lot of prose as well. Paradise Chronicle (talk) 22:36, 15 June 2023 (UTC)

You may be interested also in WP:NOTSTATS and WP:NOTCHANGELOG. If there is no context in prose, tables should not be on wikipedia is what I understand from WP:NOTSTATS. In the finals article was a lot of prose to provide context, in the Exmor was a reasonable text, but the list seemed also to me excessive. The views

(over 7000) seem ok. The NVIDIA one is really boring to me as almost no prose but this seems to be a personal preference, the views (over 75'000) give reason to believe there is some interest in such tables. Paradise Chronicle (talk) 23:05, 15 June 2023 (UTC)

Yeah, sorry for the length! I'm trying to get better about writing long passages like that—I did actually edit it down some before posting, believe it or not, but I'll be more aggressive next time. It's interesting to know that the issue extends as far as tables like this on sport articles. I guess WP:NOTSTATS could also be used to build an argument against these sorts of tables, although at least in the context of computer hardware it semes kind of hard to say how much the information qualifies as "statistics" or not. WP:NOTCHANGELOG seems more precise and I think did actually make for some strong arguments in part of the iOS version history discussion, but of course that only extends as far as changelogs. I think the level of precision in WP:NOTCHANGELOG is nice, and it would be nice to be able to answer some of these other table questions that precisely, alhough I don't know if that's practical or not. The idea that the tables shouldn't be there without prose context seems hard to pin down, on the other hand—I'm not really sure how people who disagree could answer the question of how much context is enough. A lot of these hardware-related tables have at least some amount of surrounding article where the topic of the table is mentioned. Mesocarp (talk) 01:19, 16 June 2023 (UTC)

This is basically the tip of an iceberg of dreck; it is not limited to just those pages. There were recently several very high-profile deletion discussions along the same lines (Firefox version history (2nd nomination), IOS version history (2nd nomination), and Google Chrome version history (2nd nomination)). These spurred a huge discussion at WT:NOT about the changelog thing (which mostly did not go anywhere). jp×g 17:07, 16 June 2023 (UTC)

Yeesh. Yeah, as I said, I get the impression that this is a wide-ranging issue that has probably touched many articles and will touch many more if things go on this way. I didn't realize that even WP:NOTCHANGELOG itself is part of the controversy, although I guess I'm not surprised. It is kind of strange to me how little WP:NLIST seems to be getting brought up in these discussions, since it explicitly says that each item in a list or table doesn't need to be notable as long as the whole topic of the table or list is. I think the vague wiggle room given there, though—"editors...may choose to limit large lists by only including entries for individually notable items"—is rather unfortunate and a huge source for the current conflict, though. Many people seem to be running straight to "everything in the table must be sourced from secondary sources or it goes," for basically any of these tables, which doesn't quite seem in the spirit of the existing policy to me but is technically allowed for by that kind of language. You can always say "it's too big"—it's really a matter of opinion. I don't think the ambiguity would matter as much except that it seems to be fuelling so much conflict. Mesocarp (talk) 23:07, 16 June 2023 (UTC)

Wikipedia decisions are made based on weighing multiple considerations. This area is a particular blank spot in policies and guidelines and so relies on such to an unusual degree. I think that wp:lists needs to be strengthened so that it provides more input for such discussions and in particular, to strengthen the consideration for "how likely is this to be useful for an encyclopedia reader?" For the examples given, IMO these factors/questions weigh in:

• How enclyclopedic is it? E.G. degree of compliance with wp:not. The example articles get minus points in this area. Product details on products.
• Degree of real world notability, and degree of wp:notability. Besides a basic screening function this also affects "how likely is this to be useful for an encyclopedia reader?" A software family line with a billion users would rate highly here. An obscure one far less so and the main beneficiary would probably the people owning/promoting it getting Wikipedia publicity.
• Scale/prominence of the info in the individual entries. For example tiny details that are excluded by not-a-changelog vs. listing of versions with high public visibility / identity.

Sincerely, North8000 (talk) 17:40, 16 June 2023 (UTC)

I agree that it would really help to clarify the list criteria, but it seems like a big puzzle to me at this point what should actually be done. I think any changes that would be made should be to the effect of making the list/table policies more precise, so that it's easier to settle disagreements around them. The trouble with criteria like encyclopedicity, notability, usefulness, etc. is that they're so in the eye of the beholder when it comes to these kinds of tables, and that leaves all kinds of room for very motivated reasoning. There seem to be editors out there right now who basically don't like these kinds of tables period, and for every table they want to remove, there is another group of editors equally passionate that nothing be done to it no matter what. Both groups will resort to anything they can muster to make their case, so when the policy is vague and open to wide interpretation, it becomes almost impossible to settle the debate to anyone's satisfaction. Mesocarp (talk) 23:26, 16 June 2023 (UTC)

Sports articles are another rich trove of tables of game and tournament results, statistics, records, rosters, etc., mostly thinly sourced, unsourced, or sourced to primary sources, often in articles of questionable notability. But there are passionate groups of editors building such bases on knowledge/trivia, and I think it would be unwise to try to crack down. Dicklyon (talk) 19:14, 28 June 2023 (UTC)

Disruptive behavior is not to be excused simply because of passion in fact passion makes it worse, we are after all required to edit in a dispassionate manner. If someone's passion gets in the way of them doing good work in a topic area thats grounds for a topic ban, not for looking the other way while they abuse that topic area for their personal pleasure. Horse Eye's Back (talk) 19:22, 28 June 2023 (UTC)

I didn't mean it's unwise for you to try to crack down, but it would be unwise for me. They already take me to ANI regularly just for working on their over-capitalization. Dicklyon (talk) 05:50, 29 June 2023 (UTC)

What license applies to versions of documents prior to May 31, 2023?

Wikipedia's license changed to CC BY-SA 4.0 after June 1, 2023.

So, what license applies to versions of documents prior to May 31, 2023?

CC BY-SA 3.0 or CC BY-SA 4.0? Ox1997cow (talk) 18:14, 14 June 2023 (UTC)

Obviously the old content will remain licensed under CC BY-SA 3.0 but later derivatives (adaptations) will be licensed under CC BY-SA 4.0. Ruslik_Zero 20:30, 14 June 2023 (UTC)

Can somebody ELI5 what changed? Reading https://creativecommons.org/licenses/by-sa/3.0/ and https://creativecommons.org/licenses/by-sa/4.0/ they look identical to me. -- RoySmith (talk) 20:43, 14 June 2023 (UTC)

https://creativecommons.org/Version4 may be helpful, as well as some of the other links at https://wiki.creativecommons.org/wiki/License%20Versions#License_Versioning_History . isaacl (talk) 21:56, 14 June 2023 (UTC)

CC licenses are forward-compatible by design. They're generally not backward-compatible, except for CC0, which is effectively public domain...but...designed to account for jurisdictions where there may not be a legal avenue to public domain. If you take something like an image that is 3.0 and remix it, you can license it as 4.0 with no issues, so long as you keep the same "kind" of license. You couldn't remix an image that's 3.0 and license it as CC0, because that would violate the terms of the original license by doing things like taking out the requirement for attribution. You can remix a CCBYSA into a non-commercial license, but you still have to comply with the work of which it is derivative, and the non-commercial license would only apply to your original creative contribution. GMG^talk 11:17, 29 June 2023 (UTC)

Thanks. Ox1997cow (talk) 15:33, 15 June 2023 (UTC)

RFC because we really need to relook WP:NEVENTS

[Note: I'm not sure if i'm at the right place to ask this or if i'm asking this correctly so please]

So i've noticed some issues of the community's usage of WP:NEVENTS and especially WP:EVENTCRIT. Specifically that no one even remembers these policies exist and how no knows how to interpret these rules.

Firstly, no one really uses NEVENTS at all and especially EVENTCRIT. While i have seen lots of uses of WP:ROUTINE rarely is EVENTCRIT ever even used. The only person i've seen that ever uses these is @Thebiguglyalien: and when looking at their WP:AFD nominations you can see the issues. when you look at this nom and this nom and this nom and this non you see that basically no one uses WP:NEVENTS to make their argument (though that last nom does have just one person making an argument with NEVENTS). Now, does this automatically make alien correct in their nominations, no, does this make the people voting in alien's nominations wrong, no, but does this mean that people rarely ever use NEVENTS in afd nomination about events, the very thing NEVENTS is about, yes. The collective amnesia this community seems to have when it comes to WP:NEVENTS is astonishing as no one seems to base anything on this.

But then there's the issue of how we even interpret WP:NEVENTS. There are multiple different ways people interpret NEVENTS. take a look at the ITN nom for the 2023 Yinchuan gas explosion and you can see that people have very different ideas on whether or not the article is actually notable enough to exist. Something that i've especially noticed is that interpretations of WP:PERSISTENCE is very different as well. People disagree on whether we need days, weeks, months, or even years of coverage to meet PERSISTENCE and WP:LASTING. This all results in confusion as everyone just has their own interpretations of the rules.

Because of all of this, I think Wikipedia needs to have a discussion about NEVENTS and EVENTCRIT because no one remembers these guidelines, no one agrees on how to use these, and it's just become a giant mess. Especially when so many wikipedians use WP:MINIMUMDEATHS in many of their arguments when it doesn't exist as a guideline. Onegreatjoke (talk) 20:02, 22 June 2023 (UTC)

Regardless of what conclusion is reached, this is a discussion that needs to be had (I gave up after trying to start it here and here). This huge discrepancy between notability guidelines and AfD/ITN !votes just makes things more difficult for everyone. Either we need to get rid of these notability requirements, or we need to start enforcing them. My understanding of these is that it has nothing to do with days/weeks/months/years.

Sustained coverage, as I understand it, means that the subject has received coverage after it is no longer a developing news story. For example, news reports of a disaster and subsequent updates about damage and casualties would not count toward notability, because that's coverage as it's happening (which also makes it a WP:PRIMARY source according to academic consensus, see WP:PRIMARYNEWS for explanation). But if outlets are publishing retrospective articles after all of the updates have been reported on, then that demonstrates WP:GNG/WP:SUSTAINED/WP:PERSISTENCE. Likewise, WP:LASTING isn't about whether things are happening after a certain amount of time. It's about whether another notable event happened because of it. I'll use the example on the guideline page: For example, the murder of Adam Walsh ultimately led to the Adam Walsh Child Protection and Safety Act.

I also have a solution that I think would work: these event articles don't need to be deleted. Instead, events that can't demonstrate sustained coverage or WP:EVENTCRIT should be merged into "List of X events" type articles, where each one can be briefly expanded upon without having to worry about notability. Thebiguglyalien (talk) 20:37, 22 June 2023 (UTC)

Some people have made similar arguments regarding articles on alleged UFO sightings, e.g. here. There seems to be a strong consensus at AfD that three reliable sources mean notability and that reports in quality media count even if they merely state that something happened. And there seems to be little interest in changing that.

Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. (Monty Python and the Holy Grail) -- Random person no 362478479 (talk) 09:26, 25 June 2023 (UTC)

Except that 1) we never spell out how many sources are needed to demonstrate notability via WP:N - it could take one, it could take ten. It is all about the significant coverage provided by the sources, so source counting is not an appropriate solution at AFD. and 2) WP:N and NEVENTS stress the need for both secondary sources and more than a burst of coverage. Normal every day news coverage, particularly in the immediate wake of an event, is primary, and thus while reasonable to document the event in one that is provide notable, cannot count towards notability.

AFD and in general, the creation of "news events" article, is very much broken in this area, and needs to be culled back. We have Wikinews for those editors that want to focus on news events, and should the event prove notable, we can transclude the content back into en.wiki. Masem (t) 22:35, 25 June 2023 (UTC)

Oh I don't disagree. I merely described (my perception of) the status quo and the fact that it will be hard to change this. The idea that three independent, in-depth, reliable sources are necessary and sufficient for notability is neither consistent with the guidelines nor reasonable. And if someone wants to address this problem I am completely on board (short of participating at AFD, I prefer not to venture outside civilization). -- Random person no 362478479 (talk) 17:15, 26 June 2023 (UTC)

If no one really uses NEVENTS at all and especially EVENTCRIT then the guidance does not properly describe the consensus of the community and so it should probably be removed. Thincat (talk) 18:47, 25 June 2023 (UTC)

Indeed - a more practical, if unlikely to be accepted, descriptive reading of the PAG is more something like "for an event to be notable either needs: lasting effects; ongoing coverage after the event has concluded; or a broad range of sourcing well in excess of GNG over at least 1 week" Nosebagbear (talk) 08:55, 26 June 2023 (UTC)

Don't mistake the consensus of AfD regulars with a consensus of all users. It may or may not be the same. -- Random person no 362478479 (talk) 17:17, 26 June 2023 (UTC)

Onegreatjoke, Thincat or anyone else: If NEVENTS needs to be changed, is there a specific change or wording for an RfC that should be used? Because currently a significant portion of AfD users will ignore current guidelines and claim that an event meets notability requirements simply because it was reported in the news. This is also inextricably linked to the issue of AfD users presenting news articles to satisfy GNG even though GNG requires secondary sources, which would need to be addressed at the same time. Thebiguglyalien (talk) 07:39, 1 July 2023 (UTC)

Given that WP:NEVENTS and related guidelines seem to get ignored I think you would have to change WP:GNG. Maybe add a sentence to the explication of "sources". Currently the first sentence says "Sources" should be secondary sources, as those provide the most objective evidence of notability. We could insert a clarification of "secondary" directly after that: Primary news sources on their own usually do not indicate notability. -- Random person no 362478479 (talk) 09:00, 1 July 2023 (UTC)

I find that with nearly all discussions about policies and guidelines people come along saying what they think ought to happen. However p&g documents are intended to say what does happen. These documents should be adjusted to reflect community behaviour, not to try to modify our behaviour. However, if a discussion is effective it may lead to people accepting its conclusion and following it. So, eventually, given a change in community behaviour, a document should certainly be changed to reflect the new situation. Thincat (talk) 11:43, 2 July 2023 (UTC)

You make a good point. The question here, and I don't know what the answer is, is whether or not the reality at AfD reflects a community wide consensus. Obviously, if it does, changing the guidelines is the way to go. But given that the majority of users never or rarely participates at AfD we cannot take that for granted. A discussion like this could clear this up. Currently we have a conflict between theory and practice that needs resolving. But I believe that any solution requires far more participation in the discussion. In the meantime we're stuck in a form of limbo where editors are faced with insecurity. And having people write articles without a clear set of guidelines that they can rely on is unhealthy. (Admittedly it is probably better to keep articles that don't meet the criteria of the guidelines than delete articles that do. Although the latter happens, too.) -- Random person no 362478479 (talk) 22:04, 2 July 2023 (UTC)

A new "is AfterEllen a reliable source" discussion (July 2023)

The last one was in July 2020.
New discussion at WP:RS/N > "Is AfterEllen a reliable source for BLP reporting?".
Presented as a question about use in a BLP.... Pyxis Solitary (yak yak). Ol' homo. 02:48, 3 July 2023 (UTC)

Why are you posting about an RSN discussion here? That normally isn't done, considering we'd have a dozen on here if that was consistently done. Which is rather pointless, since RSN exists for that. Silverseren^C 02:49, 3 July 2023 (UTC)

Does being compensated for research on wikipedia fall under the disclosure requirements of WP:PAID?

I plan on participating in this study that compensates its participants. Does this fall under the disclosure requirements of WP:PAID? Follow up: if so, how do I disclose? — FenrisAureus ▼ (she/they) (talk) 09:43, 1 July 2023 (UTC)

Don't worry about it. This isn't the type of paid editing that the rule is concerned with.--Herostratus (talk) 11:11, 1 July 2023 (UTC)

• When in doubt, add a simple statement to your user page if there is something (money, goods) changing hands in return for making changes on the project. Even fairly uncontroversial efforts like WP:GLAM are required to disclose. (All due respect to Herostratus above, but they're wrong.) It kinda works like alternate accounts. I haven't used a different account in a long time, and never for nefarious purposes, but I disclose them all at the bottom of my user page, including my wife's short-lived account, just in case there is any confusion.
  I would probably add a note that there is a local policy on English Wikipedia for research that can be found at WP:NOTLAB, and if this research involves making changes to content, they at the very least need to leave a note at WP:VPP. Researchers aren't always...super savvy at telling whether something could be disruptive, and... really neither is Meta or the WMF. So that's the minimum level of disclosure for them. GMG^talk 11:13, 1 July 2023 (UTC)
• The site's terms of use on paid contribution disclosure do not distinguish between reasons for being paid, so technically the terms apply. Wikipedia:Paid-contribution disclosure § How to disclose contains a brief summary, with more information available at Wikipedia:Conflict of interest § Paid editors and the documentation for the referenced templates. isaacl (talk) 15:55, 1 July 2023 (UTC)

  Thanks for your advice, I've added a disclosure on my userpage. If there are any issues with the way I've done it let me know. — FenrisAureus ▼ (she/they) (talk) 16:24, 1 July 2023 (UTC)

  Foundation lawyer working on our undisclosed paid editing terms of use enforcement jumping in here. I can confirm that if it's not a problem with the community, it's not the type of thing our terms of use enforcement is concerned with :) . Disclosure on a user page feels useful though! SSpalding (WMF) (talk) 19:11, 1 July 2023 (UTC)

• Since Jimmy Wales breaks or objectively considers breaching WP:PAID every time an A-lister inboxes him on Twitter, no one is gonna care tbh. While Herostratus doesn't speak for the letter of the law, what he says is certainly within a foreseeable purview of its spirit 🤪 SN54129 16:32, 1 July 2023 (UTC)

  Yes right. I don't care about the letter of the rules (they are not laws) but rather what is best for the project and the reader. You should too! I try to break the letter of three rules before breakfast. If the TOS "does not distinguish between reasons for being paid" well then that part is insufficiently subtle and should be ignored. Right? Motive matters, a lot.

  That said, yeah it's a good idea to explain on your user page, why not? It's just, you don't have to post your edits on talk for another editor to put in (that's not the issue here anyway tho). Herostratus (talk) 20:52, 1 July 2023 (UTC)

  "They are not laws" applies to project policies and guidelines, but disclosure of paid editing is required by the WMF Terms of Use, which are in fact binding for all editors and not directly subject to community consensus. Actualcpscm (talk) 19:37, 4 July 2023 (UTC)

• Whatever our terms are should be amended to make clear that one need not disclose being "paid" by the Wikimedia Foundation to do work on Wikimedia Foundation products. I have been compensated by the WMF in the past for beta-testing VE features in the course of normal editing, and have won prizes that were at one time offered by the WMF for the monthly disambiguation contest. Since no specific articles were implicated in either activity, I don't see this as being at all reportable. BD2412 T 20:56, 1 July 2023 (UTC)

  I'm not sure I see prizes from WMF as exactly the same as researchers from Carnegie Mellon. Wherever the draft space is where we wrote NOTLAB...I believe...we wrote it...twice or thrice over? Some people were treating this as a playground, and just figured we'd clean it up if things went badly. GMG^talk 00:23, 2 July 2023 (UTC)

• Ever since Framgate I have been aware, on this Wikipedia, of an undercurrent of rumors of unethical behavior by the Wikimedia Foundation. I have no reason to suppose that these rumors have any truth. However, in the interest of openness and transparency, whatever the source or nature of payments to users be, they should be noted on the user page, particularly if the user is an administrator. This could reduce one source of suspicion. Xxanthippe (talk) 02:17, 2 July 2023 (UTC).
• I would suggest it creates a COI with regards the foundation; for example, individuals paid by the foundation shouldn't be closing RfC's related to the foundation. Due to this I would agree that it should be disclosed. BilledMammal (talk) 02:51, 2 July 2023 (UTC)

  I disagree that participating in a study with researchers from Carnegie Mellon University and Microsoft Research creates a conflict of interest with the Wikimedia foundation. Even in the case of working with WMF staffers, I don't feel there is a future conflict of interest. Additionally, we need a healthy feedback loop for WMF development projects. I do not feel that everyone who commented on previous WMF initiatives now has a conflict of interest. isaacl (talk) 03:04, 2 July 2023 (UTC)

  I do not feel that everyone who commented on previous WMF initiatives now has a conflict of interest. No, but we're not talking about just commenting; we're talking about being paid by the WMF. Editors who commented without compensation of course don't have a COI. BilledMammal (talk) 03:12, 2 July 2023 (UTC)

  Well, this particular inquiry isn't about being paid by the WMF... If the WMF were to compensate someone with a small honorarium for participating in, say, a long-term tracking study, or with some minor swag for participating in a focus group at a conference, I don't think this necessarily creates a conflict of interest for all future matters related to the WMF. Disclosure might still be desirable for specific, related matters, but I don't think we should apply a blanket conflict of interest to all situations. isaacl (talk) 03:20, 2 July 2023 (UTC)

  If the WMF isn't paying then it doesn't create a COI with the WMF, but when the WMF is paying then I would say, without exception, that it does. BilledMammal (talk) 03:23, 2 July 2023 (UTC)

  For instance, there are many contributors who have received a free T-shirt. I do not feel this results in a bias towards or against the WMF. isaacl (talk) 03:32, 2 July 2023 (UTC)

  I'm not talking about a free T-shirt, I'm talking about financial compensation. If the WMF has paid you then you have a COI with the WMF. BilledMammal (talk) 03:36, 2 July 2023 (UTC)

  and all that the recipients of financial benefits are being asked to do is to publicly declare a COI, they are not being required to recuse themselves from editing. 03:57, 2 July 2023 (UTC).

  Exactly; they would face almost no restrictions on their editing. I believe the only restrictions it would place is that such a COI would make them WP:INVOLVED in relation to the WMF and thus subject to the same minimal restrictions any other involved editor faces. BilledMammal (talk) 04:12, 2 July 2023 (UTC)

  You suggested more than publicly declare; you also gave the example of not closing RfCs related to the WMF. I gave examples of token payment and you said "without exception". It's the blanket rule that I think isn't warranted; there are of course scenarios where payment can lead to bias or perception of bias. isaacl (talk) 04:41, 2 July 2023 (UTC)

  I gave examples of token payment and you said "without exception". By example of a token payment are you referring to the T-shirt? To be clear, I am only considering actual payments.

  You suggested more than publicly declare; you also gave the example of not closing RfCs related to the WMF. Yes; it's not possible to have a COI with an organization and also not be considered WP:INVOLVED in relation to it. It's a trivial restriction, and since we want to avoid even the appearance of bias one that is necessary. BilledMammal (talk) 04:49, 2 July 2023 (UTC)

  To be clear, I am only considering actual payments. This seems bizarre to me. Sure, a t-shirt is a trivial thing, but presumably we would consider it a declarable COI if some organisation gave me, say, a car, or paid for me to travel abroad. Gifts in kind create COI in precisely the same way that monetary payment does. If a gift of a t-shirt is not a concern, that is because it is low value and we should be equally unconcerned by a one-off monetary gift of equivalent value. Caeciliusinhorto (talk) 08:03, 2 July 2023 (UTC)

  If a gift of a t-shirt is not a concern, that is because it is low value and we should be equally unconcerned by a one-off monetary gift of equivalent value. I don't fully agree with this because of the international nature of Wikipedia. A t-shirt will be considered low-value almost everywhere but the cash equivalent will not be. Wikimedia sells T-shirts for 26 USD each; in countries like Nigeria this is the same as a person on minimum wage will earn in ~9 days, and the same as a person earning the average income will earn in ~3 days.

  It is neither practical, reasonable, or fair to try to determine whether a cash payment will be trivial for a specific editor; it is better just to consider all cash payments as causing a COI and making an editor involved, in order to avoid any appearance of bias.

  Of course, larger non-cash payments like the examples you give would also trigger a COI, but I don't believe that is disputed. BilledMammal (talk) 08:31, 2 July 2023 (UTC)

  Hmm! I attended the Wikipedia in Higher Education Summit in 2011 at the invitation and expense of the Foundation. (They even gave me a t-shirt.) Would you say that has created a permanent COI for me? I see no reason to post a notice about a COI, although there is an allusion to my attendance at the summit on my user page. Donald Albury 19:44, 2 July 2023 (UTC)

  I was about to raise the same issue! I have twice attended Wikimania with WMF financial support, including costs for travel abroad — once on a scholarship (received specifically due to the extent of my activities on the project), and once as a speaker, the last one being seven years ago. Furthermore, I have worked on numerous articles relating to the project itself, including the creation of Deletion of articles on Wikipedia, Edit count, Wikipedia coverage of American politics, and WikiProject. Is there really an implication of COI here, such that the compensation I received from the WMF should have impacted my ability to create and work on those articles? BD2412 T 20:06, 2 July 2023 (UTC)

  I would say no. A scholarship is the only reason I was in Boston at WC-NA in 2019. Columbus in 2018 just happened to be in driving distance. I don't think that's the same as a third-party researcher. GMG^talk 21:43, 2 July 2023 (UTC)

  I have historically declined the various research vouchers or cash out of an abundance of caution, but still generally say it doesn't need to be listed if you aren't making any on-wiki activity, or there is an additional reason to be concerned. Listing on your userpage/usertalk page in an abundance of caution isn't a terrible idea, but also is an annoying clutter if there forever. Perhaps a year? Re WMF grants - I believe they do need listing if they're content related in any way. They don't need listing if they fall into the above aspect of "no on-wiki activity or other significant reason to be concerned". [Disclosure: I am receiving a m:MCDC scholarship to Wikimania. Such is not listed on my userpage.] Nosebagbear (talk) 13:44, 3 July 2023 (UTC)

  My userpage is like an episode of Hoarders. I need a userpage intervention. But yes, I think the standard we tried to articulate in NOTLAB was "making any change"...and really...in any space, and not just main. I think that guides COI in a way. GMG^talk 13:53, 3 July 2023 (UTC)

  @GreenMeansGo:: My userpage is like an episode of Hoarders, have you considered just moving your entire userpage to User:GreenMeansGo/Hoard, and starting fresh? BD2412 T 23:04, 3 July 2023 (UTC)

  I already have a menagerie of subpages. I was making a bit of a joke. But I'm fine with clutter. At some point I just abandoned bookshelves and started stacking books around my house. GMG^talk 11:28, 4 July 2023 (UTC)

  Disclosure: I am receiving a m:MCDC scholarship to Wikimania. I would suggest that such a scholarship gives you some level of COI with regards to the WMF; I wouldn't be worried about disclosing it regarding edits, but I would consider it sufficient to trigger WP:INVOLVED in relation to the WMF. BilledMammal (talk) 14:24, 3 July 2023 (UTC)

  The more time anyone spends on this thread, not only engaging but even passively reading, the more time they have spent. Time that could have significant financial ramifications. Depending on the cost of your labour and opportunity cost this can either be a negligible or significant amount. People who have spent a specified amount of time reading this thread and even my comment must disclose their conflict of interest. We should request WMF to enable tracking of individual users' time in this website in order to root out undisclosed paid editing. ~ 🦝 Shushugah (he/him • talk) 15:29, 3 July 2023 (UTC)

I am afraid that the point you are making is so subtle that it has passed me by. Xxanthippe (talk) 22:46, 3 July 2023 (UTC).

If a t-shirt, conference travel or a golden Lamborghini are all gifts that must be reported, so must labor/other services be disclosed and that includes reading threads like this that seek to stretch the limits of paid disclosures all the while ignoring the most blatant inequities, namely who has the time /luxury to engage/write on Wikipedia. Yes we are volunteers here, but let’s not forget the extreme conflicts of interests that creates. The most stubborn editors have the last say when there is no policy/consensus, whether it is minute things like grammar preferences or more worrisome, in content disputes. If we are going to half-seriously consider monitoring every t-shirt transfer, we should definitely monitor the transfer of people’s time and labor into this Wikipedia. All that said, I do think paid disclosures is important, but I would hope the number of hours we put in is worth more than a corrupt t-shirt. ~ 🦝 Shushugah (he/him • talk) 23:48, 3 July 2023 (UTC)

Thanks for explaining your position, but I see nobody on this thread who wants to declare T-shirts. Declaring financial benefits harms nobody and increases confidence. In fact, if somebody does not want to declare, one might think that they have something to hide. Xxanthippe (talk) 01:02, 4 July 2023 (UTC).

Update: The project has decided to require disclosure for its paid participants. I made the userbox {{User:FenrisAureus/wikibench-disclose}} to simplify this. — FenrisAureus ▼ (she/they) (talk) 00:35, 4 July 2023 (UTC)

Request for Comment: Should editing on Wikipedia be limited to accounts only?

Should editing on Wikipedia be limited to accounts only? - jc37 15:04, 18 May 2023 (UTC)

Introductory information

Times have changed.

Technology has changed.

Online privacy laws have been created in some locales.

IP addresses have new/additional types.

And we also know more about IP addresses' usage than we did when Wikipedia was founded.

So there are some questions:

a.) With all the ways that it is just simply difficult to track by an IP address

b.) With VPN, proxies, and other such ways to mask

c.) With how there are now privacy concerns related to IP addresses

Is it time for us to just say "If you want to edit Wikipedia, please create an account".

We would still be the free encyclopedia that anyone can edit.

And as far as I know, accounts are free, and do not require any personal information.

2 other things to note:

a.) editing from an account, rather than an IP (which could be a dynamic IP) makes discussion amongst editors easier.

b.) While patrollers may spend a lot of time is spent addressing IP edits, I would imagine that that would only somewhat change, as a vandal could just create a new account instead. However, I think we'd see a small decrease in vandalism, because I think we might see fewer "impulsive" acts.

So with all that (and I'm sure, far more that others may think of) in mind, Do you think we should deprecate IP editing on Wikipedia?

I am not adding "support/oppose" sections, because this is not a vote. I think it's fair to say that this topic deserves a thoughtful discussion.

A few pages possibly worth reading in relation to this:

• Wikipedia:IP users
• Wikipedia:Personal security practices
• Wikipedia:Open proxies
• m:No open proxies
• m:IP Editing: Privacy Enhancement and Abuse Mitigation
• m:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study

- jc37 15:04, 18 May 2023 (UTC)

Discussion (requiring an account to edit)

• Editing? No. Giving article feedback, asking for technical help, etc - I'm not really seeing any reason this is a problem. I might consider "editing articles" IF enough problems could be identified. — xaosflux ^Talk 15:47, 18 May 2023 (UTC)

  Well, namespaces are numbered. the talk pages of each are odd-numbered. What would you think of limiting IP editing to the odd-numbered namespaces? - jc37 15:54, 18 May 2023 (UTC)

• If the answer is "IPs should not be able to edit" it's not clear what changes and so I don't think this ready to actually be an RfC. This feels like a precursor discussion to that RfC. Barkeep49 (talk) 15:48, 18 May 2023 (UTC)

  I'm not concerned If this ends up being a brainstorming RfC which leads to a "next step" RfC. - jc37 15:54, 18 May 2023 (UTC)

  Then I would suggest we remove the RfC tag and just let this be a policy pump discussion. We definitely should remove it from CENT (and not watchlist notice it which I'd want to do for any serious proposal). Best, Barkeep49 (talk) 15:56, 18 May 2023 (UTC)

  An RfC is an RfC. I think we can let the discussion go where ever it goes. - jc37 15:58, 18 May 2023 (UTC)

• Someone proposing to ban IPs from editing? Is it Thursday already? Seriously, can we not do this yet again. --Jayron32 15:50, 18 May 2023 (UTC)

  I think we (and the world) are in a different place on this. I think it's fair to say that wikipedia editors are not merely desktop users anymore, for one thing. Also. see some things that meta is working on concerning IP masking. I think that this topic is timely and is something we should probably discuss. - jc37 15:57, 18 May 2023 (UTC)

  I'm not aware of any serious discussion of this since ptwiki did it and there's been real research from their results. I'm also not aware of any real discussion since IP masking became something that could happen at any moment. Best, Barkeep49 (talk) 15:58, 18 May 2023 (UTC)

  I guess you're right, the last serious discussion I found on the matter was two years ago here. Still, I think it's not a good idea. We still have lots of good editing happening from IP editors, and I haven't seen a good argument that anything has changed. I see assertions that it's different now. But an assertion without evidence can be dismissed without evidence. Are IP editors really no longer making any good contributions to Wikipedia? --Jayron32 16:12, 18 May 2023 (UTC)

  I don't have links on hand, but there have been more recent discussions about IP editing within conversations about the proposed IP masking initiative, which appears to be moving forward at a slow but steady pace. (I suspect we will see more discussion when a substantial update to that comes forward, but with that in mind it's a bit difficult to have the full IP editing discussion until we have more details on how IP masking will work.) CMD (talk) 16:25, 18 May 2023 (UTC)

  Do we have evidence that those good edits from IP editors would not have happened if the editors had been forced to create an account? Account creation is pretty low friction. Seems like it would be a minor speed bump that might cause a portion of prospective editors to walk away, but surely not all of them. Barnards.tar.gz (talk) 16:30, 18 May 2023 (UTC)

  Evidence is needed to enact a change to things, if it ain't broke, don't fix it. No one has shown that it's broke. Demanding that we change a major policy merely because evidence doesn't exist not to change it is nonsensical. --Jayron32 16:39, 18 May 2023 (UTC)

  Well, the ptwiki experiment certainly seems to be evidence that requiring account creation reduced vandalism while not materially reducing edits. Barnards.tar.gz (talk) 16:45, 18 May 2023 (UTC)

  An experiment is not evidence by itself. Is there actual data about the result? ~ ToBeFree (talk) 17:04, 18 May 2023 (UTC)

  @ToBeFree There's a report by the WMF anti-harassment team here: Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Portuguese Wikipedia. 192.76.8.85 (talk) 17:19, 18 May 2023 (UTC)

  Ah perfect, I had looked for a page like this. Perhaps I had even seen that one in the past but forgotten about it. That, and the below-linked meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Farsi Wikipedia are two pages we should definitely closely look at before making a decision. ~ ToBeFree (talk) 17:33, 18 May 2023 (UTC)

• This RFC should be deferred until the imminent deployment of IP masking. MER-C 16:01, 18 May 2023 (UTC)

  Normally I would write off a proposal to block IP editing as another perennial proposal with little chance of succeeding, but the imminent deployment of IP masking is probably the most compelling reason to talk about this now. Thebiguglyalien (talk) 16:13, 18 May 2023 (UTC)

  Would IP masking mean that IP editors would change the nature of IP contributions? Which is to say, once IP masking goes live, what about the contributions of those editors who contribute without an account would change? If John Doe, who edits without an account, was providing high-quality work to Wikipedia, why would he suddenly not be doing that once IP masking goes live? --Jayron32 16:20, 18 May 2023 (UTC)

  Some IP editors – in particular the ones that edit from a single static IP address as a long-term joke/to make a point – do prefer to have a user page and/or talk page that is identifiable, like 199.208.172.35 (AKA Tarlonniel) and 76.117.247.55. It's unknown whether these sorts of IPs would leave the project or make an account (or if they give up on being identifiable and keep editing, we probably would never know!). Of course, IPs like 64.229.90.172 (whom I call "Movie Soundtrack IP"), who edit simply because they don't want another password to remember, would probably stick around. Snowmanonahoe (talk · contribs · typos) 17:03, 18 May 2023 (UTC)

  (This is the Tarlonniel mentioned above) For what it's worth, IP masking is not going to make me leave the project (or create an account) - it might actually be helpful to combat the problem of telling me apart from others using this IP (there's at least one other person who semi-actively edits Wikipedia from "here"). Of course, banning IP editing would be a big "Exit!" sign for me. 199.208.172.35 (talk) 17:16, 18 May 2023 (UTC)

  If you don't mind me asking, why is that? - jc37 17:25, 18 May 2023 (UTC)

  Because I greatly prefer editing as an IP, @Jc37 (see the FAQ on "my" talk page for links to further opinionated blathering), as do other long-term IP editors I've encountered. I can't say what they'd do if IP editing was restricted - you'd have to ask them yourself - but for me it would be a signal that, in spite of all I've tried to do in the realm of positive contributions, Wikipedia has decided to move in a direction I can't agree with, and that I should concentrate on one of my other hobbies. Or, y'know, my actual job. 199.208.172.35 (talk) 17:40, 18 May 2023 (UTC)

  I did look at that before asking and saw it seemed to essentially be a matter of preference. Thank you for clarifying. - jc37 17:45, 18 May 2023 (UTC)

  I agree. IP editing is still a net positive, and we should encourage it, especially if it inspires many IP editors to register later (as I did). We should revisit the question if and when we see the effects of IP masking. Certes (talk) 17:51, 20 May 2023 (UTC)

  Looking at what IP masking would be doing, I think it will greatly affect how my contributions are recorded, as it is kept in a cookie. As I use multiple browsers and multiple OSes, that would each have a separate identity under this scheme. I also tend to delete all my cookies every so often, which would reset the identity much more often than how long my dynamic IP address now seems to last on average (though Wikipedia crashing Chrome/Chromium-based browsers by using up all the available memory on the system (sometimes crashing the entire system instead of just the browser) and sometimes taking out all the cookies doesn't help matters). -- 64.229.90.172 (talk) 05:38, 21 May 2023 (UTC)

  or hide IP addresses. Cwater1 (talk) 20:33, 5 June 2023 (UTC)

• Jc37, you mention Tor above. When you wrote this, were you aware that editing using Tor is prevented by mw:Extension:TorBlock? ~ ToBeFree (talk) 16:59, 18 May 2023 (UTC)

  I wasn't aware of that extension. And to be honest, I was relying my my memory of the past. But, while creating this RfC, I discovered that m:Editing with Tor was marked historical, and points to m:No open proxies, which I linked to at the top. Interestingly, that page says "may block". Not "will block". And also states that some are temporarily blocked (dynamic IPs being a thing). And of course there's WP:IP block exempt and m:IP block exempt, as well. - jc37 17:09, 18 May 2023 (UTC)

  Okay; seeing it there made me worried about a potential lack of research done before starting a huge RfC. Regarding exemptions, sure, these exist for specific trusted users yet shouldn't have an effect on the discussion. ~ ToBeFree (talk) 17:28, 18 May 2023 (UTC)

  I changed the word to "proxies". Hopefully that will help prevent further confusion. My apologies. - jc37 17:49, 18 May 2023 (UTC)

• Can we get some data/discussion on how this change has gone for Portuguese Wikipedia? {{u|Sdkb}} ^talk 17:07, 18 May 2023 (UTC)

  Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study Snowmanonahoe (talk · contribs · typos) 17:11, 18 May 2023 (UTC)

  I just read that page, and it's interesting. One thing that jumps out at me is that they said vandalism was reduced. And that there was also a slight reduction of total new edits. But it doesn't seem to say if the reduction of vandalism edits was taken into account when talking about the reductoin of total edits. If the loss of total edits was (mostly) vandalism edits, I think that's worth knowing. - jc37 17:23, 18 May 2023 (UTC)

  @Jc37 Did you read the more detailed reports on the individual projects? They go into this somewhat:

  • Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Portuguese Wikipedia
  • Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Farsi Wikipedia

  192.76.8.85 (talk) 17:29, 18 May 2023 (UTC)

  Thank you. #Net_non-reverted_edits would seem to suggest an overall increase in non-reverted contributions. - jc37 17:42, 18 May 2023 (UTC)

• I've notified 2 active IP editors of this discussion. I'm aware this violates the letter of the votestacking policy, but I think it's fine because IP editors tend to not be as interested in our "meta"-discussions, and their input is obviously important. Snowmanonahoe (talk · contribs · typos) 17:09, 18 May 2023 (UTC)

  My very unhelpful input is that y'all should do what you gotta do to protect the project. I don't have any illusions that Wikipedia won't survive without me (and any idealistic fellow IP editors who might join me in leaving). 199.208.172.35 (talk) 18:01, 18 May 2023 (UTC)

  Thank you for the heads up - 64.229.90.172 (talk) 05:11, 21 May 2023 (UTC)

• Everyday, along with normal browsing, I use private browsing and/or tor/VPN. I switched to a new ISP all almost an year ago (dynamic IP addresses). In that year, I never saw "edit" option. All the IP addresses/ranges were blocked. I'm not sure how many IP addresses/ranges can actually edit. —usernamekiran (talk) 17:18, 18 May 2023 (UTC)

  Most can. The IP addresses assigned to a single ISP are likely an inconsequential fraction of the entire IP space. --Jayron32 18:11, 18 May 2023 (UTC)

  We have constant ip edits. — xaosflux ^Talk 18:15, 18 May 2023 (UTC)

  yes. But I was wondering about how many were blocked for various reasons. —usernamekiran (talk) 19:06, 18 May 2023 (UTC)

  I believe most of it is done by Special:Log/block/ST47ProxyBot. Snowmanonahoe (talk · contribs · typos) 19:08, 18 May 2023 (UTC)

  It greatly depends on country. In some, particularly in the developing world, a majority of IP ranges are blocked. In others, you're only likely to run into a rangeblock if your carrier happens to allocate IPs in a particularly confusing way. (For instance, my IP range on T-Mobile has more people on it than the population of most countries, and is blocked as a result.) -- Tamzin^{[cetacean needed]} (she|they|xe) 19:15, 18 May 2023 (UTC)

• I would tentatively support proposals to restrict IP editing in certain ways—throttling to an edit or two a minute, much more aggressive filtering of potential vandalism, more liberal use of semi-protection—but I don't see any basis to leap to the nuclear option of disabling IP editing entirely. IP editing is how I learned to edit, and how many constructive contributors did as well. ;) -- Tamzin^{[cetacean needed]} (she|they|xe) 19:09, 18 May 2023 (UTC)

  Throttling is an interesting option. Edit filters also allow automatic blocking which we have disabled, but we could enable it for IPs and autoblock IPs who run afoul of our low-false-positive, antivandalism edit filters. — Wug·a·po·des 21:18, 19 May 2023 (UTC)

  I already run afoul of those and need to file false positive reports (such as for a buggy filter, which I've done before), or edit requests for some editor with higher status who can avoid the edit filter. If I get autoblocked on top of that I think I'll just stop contributing to Wikipedia, instead of needing to file a request for unblocking every time a disallow filter is activated, and my editing privileges are withdrawn because a filter was tripped. Would you be suggesting 24-hour blocks or elevating automatic blocks, successively lengthy blocks on the same IP over the course of a year?

  As for the suggestion of only 1 edit per minute, that would mean no person could go back and correct typos they didn't notice before, and would result in a higher rate of reversions, since some patrollers revert any edit that isn't completely correct, likely sometimes with a user-warning attached, as the editor wouldn't be able to correct anything waiting for the timer to expire. It would also mean one couldn't separate edits by content, so one would need to do a massive edit to a full page, instead of individual edits to each section needing a change and what reason that was changed. Then everything would be gone with a revert as someone objected to a single sentence change and not the rest of the edit. (though that already happens with full rollbacks over the objection to a single sentence change but not other edits; as rollback seems to be default over revert for some patrollers) -- 64.229.90.172 (talk) 05:26, 21 May 2023 (UTC)

  The community has consistently rejected automatic blocking, and with good reason. Users who repeatedly trip filters are already automatically reported to AIV. 74.73.224.126 (talk) 02:21, 5 June 2023 (UTC)

• I concur with those above that this should absolutely have been workshopped better prior to running. It would be one of the most drastic RfCs we've ever run and being a reasonable question to raise needs the best pre-consideration possible. Nosebagbear (talk) 21:09, 18 May 2023 (UTC)
• Personally, I don't care whether this discussion crosses all the Ts and dots all the Is for a "proper" RfC. I'm happy just to discuss this issue in a workshop-y sort of way. Long ago, I used the userbox that says that account registration should be required for editing. But over time, I've come to appreciate that IP edits can be a good thing. I agree with the comments above, that it would be useful to examine data from the Portuguese WP. My recollection is that it worked out surprisingly well, but my recollection could be faulty. And I also think that we should be significantly guided by whether IP masking is a decision that is going to be made for us. --Tryptofish (talk) 21:49, 18 May 2023 (UTC)

  See the October 2020 announcement at m:IP masking#Statements from the Wikimedia Foundation Legal department. That decision was made a couple of years ago.

  Realistically, IP masking will start at this wiki some time next calendar year. I'm talking to the AHT team about how to make it as smooth as possible, but I'm sure there will be some bumps on this road. However, we have no real choice here. This has to happen whethe we like it or not. Whatamidoing (WMF) (talk) 23:49, 19 May 2023 (UTC)

  It doesn't have to happen, WMF just wants it to happen. -- Rockstone^{Send me a message!} 21:53, 25 May 2023 (UTC)

  The new facility offered to vandals (deleting their cookies and continuing as a new user) will probably force Wikipedia to abandon its core feature of being the encyclopedia anyone can edit. I'm not sure whether the WMF is gambling on that not happening, or sees it as less bad than storing IP addresses. Certes (talk) 22:05, 25 May 2023 (UTC)

  I really think the WMF is just trying to justify their budgets by making unnecessary changes, but that's the cynic in me. I just haven't seen (and WMF has not provided) any explanation for why this unwelcome change is needed. -- Rockstone^{Send me a message!} 22:19, 25 May 2023 (UTC)

  IP addresses can be regarded as personally identifiable information, though knowing that someone edits from 123.45.67.89 doesn't immediately reveal that it's John Smith of Kalamazoo. The WMF has decided that Wikipedia will prioritise privacy and suffer the collateral damage to vandal fighting and accessibility of editing. Certes (talk) 22:42, 25 May 2023 (UTC)

  @Rockstone35, have you read the October 2020 statement from Legal yet? Look for the words "Please understand that sometimes, as lawyers, we can’t publicly share all of the details of our thinking" – you'll have to un-collapse the section to see them. Whatamidoing (WMF) (talk) 03:30, 1 June 2023 (UTC)

  Whatamidoing (WMF) - I have, but I'm still skeptical that there's a valid reason for this since WMF won't explain their thinking... maybe I'm just cynical. -- Rockstone^{Send me a message!} 03:44, 1 June 2023 (UTC)

• I think that IP editing should be allowed because there are many great IP contributors on Wikipedia. The person who loves reading (talk) 23:45, 18 May 2023 (UTC)
• The point that would really interest me is whether there's a case to be made that "anon" editing is actually likely to be harmful to users who (despite the current warning notice) may not realize the kind of trail they're leaving. (The long-overdue IP masking initiative would change the landscape here somewhat, but only to an extent -- as I understand it, IP masking will involve pseudonymization of data but not true anonymization.) If allowing IP editing is causing editors to unwittingly compromise their privacy (in ways that we now recognize as problematic), I would find that to be a stronger argument than whatever the incremental effects on vandalism or admin workload might be. -- Visviva (talk) 00:27, 19 May 2023 (UTC)
• can't wait for the community to waste a month on this, and then waste another on the close review. lettherebedarklight晚安 01:25, 19 May 2023 (UTC)

  Not to mention the disaster that closing this discussion would be as-is anyway, given that there's no votes and just a bunch of hap-hazard thoughts spread around (apparently by design). ThadeusOfNazereth(he/him)^{Talk to Me!} 01:43, 19 May 2023 (UTC)

• I oppose banning IPs from editing entirely as we would lose a lot of productive contributors, but I would support an immediate ban in the event of the WMF deploying IP masking on the English Wikipedia. —pythoncoder (talk | contribs) 01:51, 19 May 2023 (UTC)
• I would say no, because I have felt edit-stalked since I created an account. Although I was reverted more often as a floating IPv6 editor, I didn't have to deal with others stalking my unrelated contributions. I don't mind scrutiny, but when it comes from disapproval of edits on unrelated topics, it's wrong, period. Sandizer (talk) 04:51, 19 May 2023 (UTC).
• I would oppose as a long-time anonymous editor, and I can say that, if registering were required, I probably would not be here, either because I wouldn't have noticed it, or, if I did, not do it simply because I did not want to. And there are a lot of valid reasons for IP addresses to not create accounts. 47.227.95.73 (talk) 20:48, 19 May 2023 (UTC)

  Hi User:47.227.95.73, I'm curious as to what the valid reasons are for not creating an account, and why you think you'd not be here if you had to create an account. SilkTork (talk) 12:16, 20 May 2023 (UTC)

  See my comment on my talk page. 47.227.95.73 (talk) 13:11, 20 May 2023 (UTC)

• No signs that the current system is WP:BROKE, so don't fix it. Yes, there was ptwiki's implementation of this, but that's a different wiki with a likely different culture surrounding IP editors. IP masking should fix some of the problems initially brought up, and I'm not convinced barring IP editing as a whole is going to make Wikipedia better; in fact, I think it would make it worse. Skarmory (talk • contribs) 10:17, 20 May 2023 (UTC)
• It's not worthwhile having this discussion now, when temporary accounts / IP masking is due soon. Once that change has happened and any issue have been ironed out maybe it will be necessary to have a discussion, but we can't know for the moment. The only concern I can see is that vandals can just reset their temporary account by clearing cookies, but that's only slightly easier than getting a new dynamic IP, and even then will only be an issue for non-admin vandal patrollers. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:35, 20 May 2023 (UTC)
• Too late to fix the stable door after the horse has bolted, the WMF has already wasted massive amounts of developer time on not doing this. Or too early, we don't yet know how the "IP masking" will turn out in practice. —Kusma (talk) 10:42, 21 May 2023 (UTC)
• Editing should not require an account. One of the original principles, still valid today, is (with my emphasis here) "You can edit this page right now ... We must respect this principle as sacred." It is not "you can edit this page after registering and logging in". This principle is common to all Wikimedia projects (with my emphasis here) "The ability of almost anyone to edit (most) articles without registration."
  In a world where everything wants me to register, have an identifier (even if it's not required to be my real name), have a separate password to keep track of, it's a refreshing change to have something that just lets people do something (edit) without having to jump through hoops first, no matter simple those hoops may be.
  Recording and displaying IP addresses is a privacy issue, but the solution is to limit the recording/display of IP addresses (which presumably IP masking will do), which can be done independently of registration. In any case, if we choose to record/display IP addresses, but tell the editor first, then it is the editor's choice - they always have the choice to create an account, but we do not require it.
  There will be vandals and other bad actors, and making people register might deter some of them, but one of Wikipedia's guidelines is to assume good faith, so we should do that for an anonymous editor - to ask people to register so as to make it easier to reduce bad actors is effectively to assume bad faith. The price of "anyone can edit immediately, without registering" might be an small increase in vandalism, but I think that is a price worth paying for our principles. Mitch Ames (talk) 12:43, 21 May 2023 (UTC)
• Prohibit Masked edits. The WMF has declared that IP-editing is going to be terminated, and they consider that non-negotiable. They intend to replace it with Masked edits, hiding logged out users behind temporary coded identifiers. This will only increase the aggregate problems caused by logged out users, and it will only make it more difficult for the community to deal with them. This significantly shifts the cost-benefit calculus. We need to establish consensus and bar Masked edits before the WMF turns them on, because if we allow so much as a single Masked edit we're stuck with these new coded-identifiers stuck in our database forever. Many of our tools and software will BREAK whenever they encounter one of these edits in history, many of those tools will never get fixed, and all future tools will have to deal with these junk-identifiers forevermore. I fear the WMF is going to screw itself with permanent software headaches if they enable Masked edits anywhere, and it's ultimately abandoned. The need to keep the junk-identifiers in the database permanently for attribution reasons, leaving them stuck supporting the random garbage identifiers in all of their software forevermore. Alsee (talk) 15:11, 19 June 2023 (UTC)

  The "junk-identifiers" will be reserved by MediaWiki anyway. Snowmanonahoe (talk · contribs · typos) 15:18, 19 June 2023 (UTC)

  Identifiers being reserved isn't the problem; being used may be. More generally, if we can't effectively fight vandals who conceal their IP addresses, there is a case for blocking IP editing from the moment IP masking is released rather than later. In other words, we'd prevent IP masking from happening on this wiki; the new code (which runs when an IP edits) would be released but never executed here. For 13 years, I've displayed a userbox supporting the right of anonymous users to edit Wikipedia, so I don't suggest blocking IPs lightly, and it's hard to tell yet whether it would be worse or less bad than IP masking. Certes (talk) 18:10, 19 June 2023 (UTC)

  Alsee, you begin your argumentation with the (for me, astonishing) claim that, The WMF has declared that IP-editing is going to be terminated. Can you provide a link to someplace where the WMF states this so clearly (and non-negotiably)? Also, if that's true, why would the WMF screw around with the complexity of masked IPs and not just go directly to "logged-in editing is required on all platforms starting on yyyy-mm-dd"? — JohnFromPinckney (talk / edits) 20:15, 19 June 2023 (UTC)

• I think this would be net negative as it may drive away prospective editors who would have created an account at a later point and contributed. I started editing Wikipedia as an IP long long ago. Created an account less than 5 years ago, and became a regular contributor less than 3 years ago. I do not think I would be contributing here today if I hadn't begun editing as an IP. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:52, 19 June 2023 (UTC)
• Not a good idea. As many others have said, this could drive away potential newcomers, and... uh... doesn't this kind of go against WP:5P3- Wikipedia is free content that anyone can [...] edit. Edward-Woodrow :) _[talk] 22:10, 28 June 2023 (UTC)
• Strongly Disagree I concur with many of my fellow editors, Wikipedia may have a editor crisis in the upcoming future. I feel like it would be to drastic of a policy change that could upend the system.--Trey Wainman (talk) 05:47, 30 June 2023 (UTC)
• Disagree. 1) The encyclopedia's resilience to anonymous editing is an important statement of our ideal of openness, of the power of altruistic volunteerism, of the original spirit of the project. 2) While changing this rule may reduce vandalism quantity, the quality of anonymous vandalism is mostly low. We would be changing our ideals to reduce a problem that is quite easily, and generally is, solved -- while not making progress against the more pernicious problems of sponsored editing and subtle but invidious ideological editing. Chris vLS (talk) 00:54, 5 July 2023 (UTC)

Discussion about the RfC

• I would recommend Idea Labing the proposal first before this turns into a trainwreck. Curbon7 (talk) 19:23, 18 May 2023 (UTC)

  Jc37, How dare you call my comment essentially useless bureaucracy when I'm giving you advice on how to make your RfC stand on two feet rather than flop like a fish out of water. Sectioning off comments like this might be one of the most inappropriate things I've seen in an RfC, especially considering this is formatted as an open-ended discission. Curbon7 (talk) 00:22, 19 May 2023 (UTC) Resolved. Curbon7 (talk) 03:29, 19 May 2023 (UTC)

  I appreciate that your suggestion may have been well-meant.

  Discussion of the question proposed? above. Discussing the RfC itself? right here. Your statement was one of "venue", and has nothing to do with the question of "whether Wikipedia limits editing to accounts". Whether intended to be or not, these arguments are essentially just WP:NOTBURO arguments. Do it this way, not that way, have the discussion there not here. There are also some who are attempting to predict the future, but that's still not addressing the question of the RfC, and still just about the RFC itself. - jc37 00:35, 19 May 2023 (UTC)

  Upon further reflection, and re-reading your comments, I decided to remove BURO from the heading. I didn't ever say or imply that your seemingly well-meant suggestion was "useless", and I am sorry that you interpreted it in that way. - jc37 02:15, 19 May 2023 (UTC)

• @Jc37: I just removed the RfC tag, and this from CENT, but you have reversed me. This is not formatted like an RfC, especially given that this appears to be a de facto referendum on IP editing. Where is the brief and neutral statement? You have provided a rationale, not a neutral RfC question. The proper way to do this would be to set forth a short, neutral question or prompt, and then put your rationale as say the first comment. Instead, this looks like a pre-RfC, designed to workshop an eventual RfC. You can't just slap an RfC tag on anything you want more people to look at, and you especially can't just put it at CENT. Please self-revert. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:40, 18 May 2023 (UTC)

  a.) This is an RfC, per WP:RFC. "A request for comment (RfC) is a request to the Wikipedia community for comment on an issue." In this case: "Should editing on Wikipedia be limited to accounts only? " b.) it follows the way we have created RfCs for decades. c.) Actually an RfC question does not need to be neutral. It just needs to be a question. Perhaps you are thinking of a neutral notice about an RfC. - jc37 19:53, 18 May 2023 (UTC)

  ​ Um... from WP:RFCOPEN, #4: Include a brief, neutral statement of or question about the issue in the talk page section (emphasis in original). So yes, an RFC question does need to be neutral. Primefac (talk) 19:59, 18 May 2023 (UTC)

  First, this isn't on a talk page of an article or policy page, because it's an overall policy. I put it at the VP - which is what we do - look up for examples.

  Second, "Include a brief, neutral statement of or question about the issue - I did. look at the top. I not only provided the question (which the bot copied). but I also explained. it.

  So I followed that. - jc37 20:14, 18 May 2023 (UTC)

  WP:RFCNEUTRAL → Keep the RfC statement (and heading) neutrally worded, short and simple. 192.76.8.85 (talk) 20:02, 18 May 2023 (UTC)

  As I noted above, I agree that this is not really fit as an RFC and so I have re-removed the tag. Obviously discussion can (and should) continue to see if there's something that should be proposed as an RfC. Best, Barkeep49 (talk) 20:04, 18 May 2023 (UTC)

  In what way do you think this does this "not really fit as an RFC"? All an RfC is, is a request to the community for comment. That is exactly what this is. And the question is very straight-forward - "Should editing on Wikipedia be limited to accounts only? ". - jc37 20:17, 18 May 2023 (UTC)

  If the RfC question was the header, that is a bad practice. Further, it makes your !vote look way more important because you have made it appear as if your comment is in fact the RfC prompt. Look, a discussion about IP editing was inevitable. But such a conversation will be extremely contentious. It will take a well crafted RfC to ensure consensus can be found. But what you've created here is not designed to create consensus. It will be a nightmare to close. You assume there won't be voting, but I'm almost certain that before the halfway point it will devolve into supports and opposes. Further, you have not followed WP:RFCBEFORE to workshop this RfC, which is evident in the fact that we're having this discussion. Overall, this is an important conversation that will have to be had at some point. But doing it prematurely or poorly will only serve to delay the issue. This is just not the way to do it. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:43, 18 May 2023 (UTC)

  This isn't a "vote". And second, you can tell the RfC prompt by the first signature - that's why it's there. And it's all above the "discussion" heading, so it's clear that it's the introduction. Just... like... any... other... RfC...

  And yes, this is important. And I did a fair amount of reading before hand, or I would not have started it. I'm not stupid or naive.

  As for closing, we've had discussions on Wikipedia before now, including fundamental ones like this, and they managed to close them. - jc37 20:54, 18 May 2023 (UTC)

  While we're all aware that consensus is not a vote, this discussion simply is not set up to arrive at a meaningful consensus. You wrote a handful of brief, vague sentences, gave us half-a-dozen links of optional reading, and asked us to discuss amongst ourselves. I really don't foresee how this RfC will lead to a substantive result. I see that you commented above that you wouldn't mind if this became a brainstorming RfC; well, I think that's all it can be. LEPRICAVARK (talk) 06:35, 20 May 2023 (UTC)

  No, I wrote 1 straight-forward question: "Should editing on Wikipedia be limited to accounts only?". Then I wrote some explanatory text after it, including (some of) why I am asking the question. What I said above was that I am not placing a preconception on what the result of this RfC will be, and am content that the discussion (and thereby, the community consensus) goes where ever the community takes it. We've had RfCs designed to "force" commenters to respond in one way or other. (and in reading some responses here, it's apparently a shock to some that I'm not trying to do the same in order to force a certain outcome.) But this isn't that. I think this is too important, too fundamental a question to do that. Everyone should be able to have their say on this question and not be railroaded by anyone trying to "herd cats" in a certain direction. Let the community have its say. And once it has, it can be determined if the community has come to a consensus. I find anyone trying to upend that, honestly, is merely being disruptive, whether intentionally or not. - jc37 00:27, 21 May 2023 (UTC)

• In re-reading the above, and thinking about the fact that we're talking about a template that merely summons a bot to add a notification, I'm thinking that everyone involved could use a WP:TROUT, and some time re-reading WP:NOTBURO. The idea that you all seem to be suggesting that there are RfC discussions and then there are "special" RfC discussions, is rather an eye-opener, to be sure. - jc37 20:54, 18 May 2023 (UTC)

  The most blatant problem with this RFC could easily be fixed by jc37 moving everything past the first line into the discussion section. Could you just do that and see if anyone objects to anything else? Phil Bridger (talk) 21:00, 18 May 2023 (UTC)

  Looking at Wikipedia:Village_pump_(policy)#RfC_on_a_procedural_community_desysop and Wikipedia:Village pump (policy)#RFC: MOS:GENDERID and the deadnames of deceased trans and nonbinary persons, as examples, I can add an additional header, if that helps resolve concerns. - jc37 21:06, 18 May 2023 (UTC)

  The issue is important but this proposal is deeply counter productive. The main problem is that this is guaranteed to fail—it is too soon after the last couple of failed attempts, and it is too early before we see the consequences of IP masking. We could have a stirring argument but a proposal to limit editing to accounts will fail at the moment. The secondary problem is that having yet another failed argument will poison the well for the future. My prediction is that IP masking will be problematic, but I'll keep an open mind and see what happens. A pointless argument now will only make it more difficult to raise the issue again if IP masking is a problem. Please just drop it. Johnuniq (talk) 00:05, 19 May 2023 (UTC)

  Funny how this started about should IP users be banned from editing the wiki to Admins and above have different views on different policies. I (and some who have no choice like Russia, North Korea, etc.) either prefer to edit as an IP or do not want to create an account that can be traced back to them. If a user creates an account they are prompted for their email so now their privacy to those countries is blown away. Not a good idea. It’s great those smaller wikis had done test runs but come-on English is the largest wiki and the most targeted. The more restrictions put on WP the harder it is for anyone to edit. I’m on AT&T first response network and I’m blocked in a range block if I’m not on a wifi somewhere. Some networks you have already blocked have numerous blocks against them and the blocks won’t expire for a couple of years (which I believe is not the policy). So if you want to turn off IP editors I personally feel you will lose a lot of editors. Admins and up are in place for a reason and I feel this is an attempt to stifle IP editors and to lower the work load for admins. Hey if you admins don’t want the work, turn over your mop. — Preceding unsigned comment added by 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 02:07, 19 May 2023 (UTC)

  Giving an email address is optional. And if you do provide one it is not available to the public. Snowmanonahoe (talk · contribs · typos) 02:24, 19 May 2023 (UTC)

  It may be optional but if they forget their password, they would need to create yet another account and there is no policy on deleting old user named accounts that haven’t edited in years. 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 06:43, 19 May 2023 (UTC)

  Your edits are not "deleted", whether done as an account or an IP. As for the account name, there's always WP:RTV. - jc37 08:57, 19 May 2023 (UTC)

  @Jc37 you completely missed that point. Why would someone want to use vanishing because they forgot their password? Maybe they want it to be credited to them but they make complicated passwords or mistype it? You are looking at this as you are the iron fist (from what I’m reading throughout this conversation, and so addressed by other editors) that you won’t take any other answer other than block all IPs. This will drive away new editors who are dipping their toes in the water before wanting to even commit to creating an account. Also you used, once again, a guideline and not any policy. Granted you are pretty passionate it seems about banning IP addresses and uprooting the Encyclopedia that anyone can edit to Encyclopedia that anyone who gives us their information can edit. 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 17:32, 19 May 2023 (UTC)

  I was merely responding to "...and there is no policy on deleting old user named accounts that haven’t edited in years". As for the rest you are welcome to your opinion, but I believe you completely mischaraterize me and what I've said. - jc37 17:45, 19 May 2023 (UTC)

  I'm struggling to understand what it is you want. When you edit logged out you give the world access to your IP address which can be used to determine your rough location. You seem to at least be aware of the fact you're editing from an IP, so I'll assume you're ok with that. So why exactly is it better that the whole world knows where you live, than giving the Wikimedia Foundation (and no one else) your email address, which I remind you, is not something you even have to do? And why do you need the old account to be deleted if you lose access to it? Snowmanonahoe (talk · contribs · typos) 17:50, 19 May 2023 (UTC)

  This is deeply misguided. Anyone concerned with privacy should immediately stop editing as an IP, and create an account. CMD (talk) 04:58, 19 May 2023 (UTC)

  ...isn't it more dangerous to have your exact IP visible in Russia/North Korea than an account without an email? A prompt for an email in these countries, under your explanation, would be ignored by anyone that cares about their safety, and if they don't care about their safety this comment is no longer applicable by my understanding. Skarmory (talk • contribs) 07:46, 20 May 2023 (UTC)

  @Jc37@Skarmory@Snowmanonahoe@CMD - Most people in those countries and a few others like the great firewall of China use VPNs so that covers their tracks to get to Wikipedia and possibly edit it unless someone blocked the entire range (as I mentioned early that AT&T and T-Mobile cellular networks are completely range blocked) and to get around that as a non-admin requires extra work and if I remember correctly when requesting that flag you have to submit a utrs that includes your personal information to those who have access to that queue. That is where the privacy issue then comes into play. 2600:8801:CA05:EF00:95AD:57F8:C033:7A83 (talk) 11:09, 20 May 2023 (UTC)

  The only personal information that gets submitted in an IP-block exemption request is your IP address, and only to administrators. Snowmanonahoe (talk · contribs · typos) 13:22, 20 May 2023 (UTC)

• Shouldn't we wait for a while after IP masking is implemented before making this decision? Sandizer (talk) 04:53, 19 May 2023 (UTC)

  Waiting to see how IP masking works out in practice seems like a reasonable and prudent choice. 68.189.242.116 (talk) 16:09, 19 May 2023 (UTC)

  I think we know some bits, enough to resolve a few of the questions that @Jc37 opened above, and maybe to add some more. Among them (numbered for convenience):

  1. The new "temporary accounts" (see mw:Help:Temporary accounts and mw:User account types) will have some predictable username pattern. This is being discussed on Meta-Wiki (join!). I think the current idea is that the username format will be User:~2023-123456, but it's not final. The number in the username is just a steadily incrementing number. The first account will be "1", the second will be "2", and by the end of the first year, we'll probably be up above ten million.
  2. The temporary account will be per-browser (cookie based), not per-IP. If you use the same device/browser, it'll be the same username no matter where you are editing from (at home, at school, at work, via VPN, etc.). This will make it easier to track some editors, but not necessarily everyone.
  3. Pretty much everyone who is active in this discussion will be able to "reveal" the full IP address. See foundation:Policy:Access to temporary account IP addresses and m:Access to temporary account IP addresses FAQ.
  4. This should improve privacy for these editors overall, but it's not a pure, unmixed improvement. In particular, if a temporary editor uses multiple IP addresses, you'll be able to see all of them (for the 90 days that we keep them).
  5. If you think this is going to make tracking people harder, then please read up on the changes to Chrome, which are going to hide editors' (actual) IP addresses. Chrome might end up being a bit more like T-Mobile or the iCloud Private Relay system than it is now, and that's the most common web browser among editors.
  6. We'll be able to ping editors using temporary accounts and otherwise have a much easier time communicating with temporary accounts than with IP editors (especially dynamic IPs).
  7. It might be possible to stop some of the m:Talk:No open proxies/Unfair blocking problems since we won't be relying solely on IP addresses.
  8. Some tools will need to be updated. We have months to get this done in, but it will be work. Realistically, some tools will break, and some will be unfixable. It might also open other opportunities for new and better tools.
  9. Help pages and other documentation will need to be updated. It's probably too early to do that work, but it's not too early to make a list of key pages.

  I'm sure there are other relevant points, but perhaps this is enough for a Friday evening. Feel free to ask questions. Whatamidoing (WMF) (talk) 04:32, 20 May 2023 (UTC)

  @Whatamidoing (WMF), I'm curious:

  1. Will the cookies be persistent or per session?

  2. What happens if someone has cookie blockers set up?

  3. I'm not entirely sure how the mobile apps work - will each launch of the app be treated as a new browser session, with a new ID assigned? 199.208.172.35 (talk) 20:14, 22 May 2023 (UTC)

  1. Persistent, up to some reasonable length of time. This is currently set to one year, but could be shorter. I've seen a proposal that's as short as 90 days. (I personally prefer a full year.)
  2. They'll get a new temporary account each time. If they don't like that, they'll need to accept cookies from Wikimedia websites.
  3. The apps should look basically the same as the website (from the POV of the user) in this respect, so you'll get a temporary account on your first edit and re-use it until it expires. (However, since it's impossible to log in to a temporary account, if you edit from the app + the website, those will be two separate temporary accounts.)

  Whatamidoing (WMF) (talk) 00:09, 23 May 2023 (UTC)

  Very interesting, thanks! Perhaps the most interesting point is #6. Guess it's going to be much harder for me to pretend I didn't see something. 199.208.172.35 (talk) 14:42, 23 May 2023 (UTC)

  @Whatamidoing (WMF): Will we be able to see all the temporary accounts coming from an IP address, or ideally a range of them? Snowmanonahoe (talk · contribs · typos) 22:47, 25 May 2023 (UTC)

  This is an open question, and I believe that Legal will have to answer their part of it before Product will figure out whether it's technically feasible (i.e., without making major changes to MediaWiki). The legal answer might sound like "only for Stewards, CUs and others who have signed up to the m:Access to nonpublic personal data policy" (or it might not; that's the thing about waiting for legal advice).

  On the community side, I believe there are concerns that this could be too similar to a Global CheckUser, which has not been an especially popular idea in the past. A vandal could use multiple IPs in a range, but so can innocent, unrelated editors. Whatamidoing (WMF) (talk) 03:26, 1 June 2023 (UTC)

  @Snowmanonahoe, the AHT team is looking into this. We have no promise that it will happen, but I consider this a step in the right direction. My best guess is that we probably won't have any more/clearer information until at least September. Keep an eye on m:IP masking; that's where they're making official announcements. Whatamidoing (WMF) (talk) 19:35, 9 June 2023 (UTC)

  Things are changing? Cwater1 (talk) 02:29, 10 June 2023 (UTC)

WP:PERFNAV should be removed

I think it is perfectly reasonable for a show's or film franchise's head creatives and production companies to be mentioned on their navigational boxes. As such, I think this policy should be removed or significantly altered. @Woodensuperman: @WikiCleanerMan: (Oinkers42) (talk) 19:14, 3 July 2023 (UTC)

The last clause of WP:PERFNAV — "... unless the individual concerned could be considered a primary creator of the material in question." — appears to directly address your request. Doesn't it? – .Raven  .talk 20:19, 3 July 2023 (UTC)

I have heard that it only applies to film for some reason. (Oinkers42) (talk) 22:12, 3 July 2023 (UTC)

The sentence "This includes, but is not limited to actors/actresses, comedians, television/radio presenters, writers, composers, etc." seems to make clear that broadcast media are included. So when later the section says "filmographies (and similar) of individuals", that would mean career histories in not just "film", but also other media. – .Raven  .talk 00:02, 4 July 2023 (UTC)

No, that clause is for filmography navboxes, per WP:FILMNAV, i.e. it's okay to include a filmography for directors etc. For the navboxes for the franchises, etc, WP:PERFNAV applies, where we don't include cast and crew. --woodensuperman 07:58, 4 July 2023 (UTC)

Okay, but for clarification, please: what constitutes the "and similar", in the "filmographies (and similar) of individuals"?

A career history in film, by listing films, is a filmography. What's "similar" to that, still in film, except another filmography?

Actors in television have "similar" listings by TV shows. Actors who do both film and TV have histories which list both. – .Raven  .talk 12:12, 4 July 2023 (UTC)

Discographies, bibliographies, etc. But the actor is not a primary creator of the work, therefore we do not have actor filmography navboxes. --woodensuperman 12:42, 4 July 2023 (UTC)

Strong objection to removal. This is a good long standing guideline as it prevents over-proliferation of navboxes. Also, that would then allow actors being present in navboxes. But, imagine if there was a navbox for every TV series that Steven Bochco created. What would his page look like? {{Steven Bochco}} is fine though, per WP:FILMNAV Also, how do you define a franchise head without meeting WP:UNDUE concerns? For {{Indiana Jones}} for example, is it Spielberg, Lucas, or even Kasdan?. --woodensuperman 08:00, 4 July 2023 (UTC)

WP:PERFNAV also mirrors WP:PERFCAT in that we would not put, say Chuck Lorre in Category:The Big Bang Theory, but we would put The Big Bang Theory in Category:Television series created by Chuck Lorre. In the same way, we put The Big Bang Theory on the navbox {{Chuck Lorre}}, but we do not put Chuck Lorre in the navbox {{The Big Bang Theory}}. --woodensuperman 09:57, 4 July 2023 (UTC)

Well, which "individual concerned could be considered a primary creator of the material in question"?

If more than one, don't we have a Rodgers and Hammerstein-type situation, where we don't say just one? – .Raven  .talk 12:18, 4 July 2023 (UTC)

You mean like {{Rodgers and Hammerstein}}? Note that WP:FILMNAV says "a" not "the" primary creator. I'm not really sure what your point is, as this is about the first WP:PERFNAV clause of the guideline, not the WP:FILMNAV part. --woodensuperman 12:42, 4 July 2023 (UTC)

The two parts of the guideline used to be separate. Maybe that merge could be the source of the confusion. --woodensuperman 12:51, 4 July 2023 (UTC)

Likely. Thanks for your time in explaining it. – .Raven  .talk 14:19, 4 July 2023 (UTC)

Look, all I am saying is that we include creatives (not actors) that have this franchise as one of their defining works and (in general) vice versa (to answer your question, Spielberg and Lucas would both be included, alongside the major production companies). Maybe removal was too harsh, but I think a change is in order. (Oinkers42) (talk) 17:52, 4 July 2023 (UTC)

See {{Steven Spielberg}} -and- {{George Lucas}}, both originally created in 2006. – .Raven  .talk 00:37, 5 July 2023 (UTC)

I couldn't disagree more to be honest, in fact, I think we should actually be more stringent when it comes to creatives and expand the guideline to other fields. If you take the comics field for example, look at the sheer number of navboxes at Stan Lee. This many navboxes does not make for easy navigation between articles, the whole point of the navbox in the first place. We wouldn't include Stan Lee in the category Category:Spider-Man, the same principle could easily be applied to inclusion in navboxes. In any case this kind of thing is what would happen if we added creatives and to navboxes. And as far as production companies go, this is an absolutely crazy idea, imagine what the Disney or Marvel page would look like with all of their franchises on. I maintain that WP:PERFNAV is to be applauded and no softening of the guideline would be helpful in aiding navigation. --woodensuperman 08:31, 5 July 2023 (UTC)

> "look at the sheer number of navboxes at Stan Lee."

Considering his career and its effects, I'm not at all surprised.

> "This many navboxes does not make for easy navigation between articles...."

Mm. Their bodies are hidden, their descriptive labels ease burrowing down in the reader's area of interest: does one want to know more about which media he worked or appeared in, the awards he received, the characters and series he created, or the company with which he was chiefly associated? Organized like this, I think it's actually easier to get good pictures of the topics than in one massive navbox containing everything "flat-filed". There are simply too many articles related to him and his creative work, NOT to use subgroups. – .Raven  .talk 14:22, 5 July 2023 (UTC)

Considering the amount of delving you have to go through to even find the navboxes, this does not make for an efficient navigational system. A navbox works best when it navigates a simple set of articles. Over-proliferation of multiple navboxes negate the navigation function: you might as well look at the article if it gets too complicated. This is a perfect example of when it all gets too much. --woodensuperman 15:23, 5 July 2023 (UTC)

Revision deletion and oversight for deadnames

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

MOS:GENDERID stipulates that former names of transgender people ("deadnames") who were not notable under that name should be treated as a privacy interest. Whether revision deletion or oversight should be used for usch names has as far as I know been discussed twice: at Administrative action review, and at the MOSBIO talk page. Both discussions were largely positive towards revision deletion. In November, I tried to add relevant wording to MOS:GID, based on the latter discussion, but was reverted. Today there was also a discussion on IRC concerning this topic, which ended in a revision deletion, but there was some discussion between admins on what the appropriate reaction is, and there was a consensus that clarifying this explicitly would be good.

Given the inclarity in the IRC discussion and the paucity of guidance on this, I think it'd be best to have this settled explicitly. I'm asking for input on community feelings around the use of revdel or oversight on such names. Also, if it is appropriate, should we amend MOS:GID and/or WP:RD to say something about it?

Pings for the participants of the IRC discussion: @AzaToth, Barkeep49, Primefac, Sideswipe9th, and Tamzin: -- Maddy from Celeste (WAVEDASH) 21:53, 26 June 2023 (UTC)

It should be used with caution - it shouldn't be used when there is a valid argument for inclusion as that stifles discussion, and it shouldn't be used if the deadname is used by sources as in those circumstances it is needed to help find and understand those sources. BilledMammal (talk) 22:33, 26 June 2023 (UTC)

I think the best policy would be revdel if reliable and secondary sources don't include the information, but don't revdel if they do. This allows us to balance the privacy interest with the needs of the encyclopedia; it allows us to find and use suitable sources that use the deadname, it allows us to consider circumstances where MOS:GID is not controlling, and it is in line with WP:NOTLEAD. BilledMammal (talk) 01:20, 27 June 2023 (UTC)

When a deadname counts as private information, it's usually oversighted, similar to a home address or personal phone number. The edit at issue here was a marginal case: Rachel Levine was not notable under her deadname, but that name has been reported in reliable sources including The Washington Post, so the name can't be considered private in the same manner as some other people's deadnames. In these borderline cases, I think discretionary revision deletion is in accord with at least the spirit of RD2, and arguably the letter depending how you parse that criterion. The two discussions Maddy mentions (the first of which arose from some revdels I made) seem to show that the community is okay with admins treating deadnames as either RD2 or an IAR basis to revdel, subject to common sense. I'm not sure if we need to write that down anywhere, when all instances of it that I'm aware of have been upheld. But maybe a footnote could be added to WP:REVDEL if desired. -- Tamzin^{[cetacean needed]} (she|they|xe) 23:03, 26 June 2023 (UTC)

I just proposed a revision to MOS:GID here that aligns it with BLP privacy. One implication is that some revision history needs to be removed (although as Mitch Ames pointed out, that should probably not include talk pages). Cuñado ☼ - Talk 23:06, 26 June 2023 (UTC)

We just had a HUGE RFC about deadnames… can’t we give it a rest for a while? Blueboar (talk) 23:16, 26 June 2023 (UTC)

While I recognise that there is an element of discussion fatigue here, this specific issue of when and when not to revdel a deadname came up today on the IRC revdel request channel and some of the admin participants felt it warranted on-wiki discussion. In my experience we receive/make a not insignificant number of these requests every day, and as I've elaborated in my reply below, getting this wrong has demonstrable harmful effects. So unfortunately we kinda do have to have this discussion now. Sideswipe9th (talk) 01:05, 27 June 2023 (UTC)

I'm broadly on your side policy wise in these matters, but I disagree with the assertion that since it came up recently, we have to have the discussion now. I'm not seeing a strong argument that this can't be handled through existing policy on a case-by-case basis, but I am seeing (and experiencing) fatigue with the topic. I think better results are more likely if this isn't hammered at with such frequency. Respectfully, Folly Mox (talk) 01:35, 27 June 2023 (UTC)

I have to agree. Sideswipe, I also agree with your general objective in these discussions much more than I disagree, but you have to slow down and think about how you are going about this process, because I think your current approach is much more the cause of your inability to get a firm consensus, rather than it being an issue with the general level of support for moving the needle on this policy. I think it's just getting very easy (for people who are ambivalent/looking for reasons not to act, especially) to just interpret this whole cluster of discussions as process bludgeoning, for lack of a better term, because it comes from the same small handful of people repeatedly, with swift turn-arounds on sequential RfCs and even concurrent discussions. And if my memory is serving me faithfully, it's you more than any other single editor. Now, we're here, so we might as well discuss and figure this out, but honestly, you would do your own preferences a big boon in getting picked up in the long term if you made this the last WP:PROPOSAL you make in this area for a while. My honest opinion is that this is true "the pause would benefit the cause" territory. SnowRise ^{let's rap} 13:48, 29 June 2023 (UTC)

Actually, while I think we should be having this discussion because of the risks to harm to BLPs if we get this wrong, and I was involved in the IRC discussion that lead to this thread being opened, I was not the editor who suggested that we discuss this on-wiki. As I said in my reply at 01:05, 27 June 2023 it was an admin participant in that discussion who felt we needed to discuss this now, so please do not direct any ire at me. Sideswipe9th (talk) 14:02, 29 June 2023 (UTC)

Fair enough, you're right: you can hardly be considered the architect of this discussion. But let me be clear that my concern should not be confused with ire, nor dismissed as to the broad strokes. I support change to the policy: I just want the discussions to be viable vehicles for that change, and having them back-to-back-to-back and always involving the same basic cast of major proponents (on more than one 'side' to be sure), it just begins to feel like a contest of wills. That's not a great status quo when the margins for consensus are so thin, and divided across several sub-issues. I'm honestly not trying to give offense nor to vent: I'm trying to explain why we are spinning our wheels and appeal for everyone to take a few steps back after this current wave of RfCs. I erred insofar as my comment might easily be taken to suggest you opened both this and the previous discussion unilaterally. That's not what I meant to say. I'm just urging giving everyone a little break to digest. SnowRise ^{let's rap} 14:29, 29 June 2023 (UTC)

"And if my memory is serving me faithfully, it's you more than any other single editor."

I just want to clarify that I dragged Sideswipe9th into helping me start the RFC-before-last, so I'm not sure that the prominence of her name on that RFC should be counted against her. I also think it was, at the very least, fair to start the last RFC given that it was specifically suggested by the closing statement of the first RFC.--Jerome Frank Disciple 14:02, 29 June 2023 (UTC)

Understood, but let me again be clear that I am not suggesting misconduct or bad faith here. I'm talking purely a matter of pragmatics and discussion strategy. GENDERID is like the new infobox wars: Everytime I see a notice in this area in the last year (and recent months in particular), I know like eight people who for a fact will be there if I follow it. That makes the discussion easy to personalize and entrenches positions, especially when no real pause is taken between iterations of the discussion. SnowRise ^{let's rap} 14:41, 29 June 2023 (UTC)

Speaking in generalities, there's three types of deadnames that are of relevance here I think. Of course like anything we discuss, there are exceptional cases which don't fit neatly into any of these types, and may warrant an individualised response. For the most part, I'm going to use language here that mirrors the current version of MOS:GENDERID.

• The first type is the deadnames of people who changed their name after the point at which they're notable. Per the third paragraph of GENDERID those names are typically, but not always as local consensus can form to exclude, included somewhere in the biographical article of that person. For this type of deadname, no REVDEL is warranted, even when there is a local consensus to exclude the name. These individuals are typically public figures, and within reason the concerns in WP:BLPPRIVACY and WP:BLPNAME have a lesser concern.
• The second type is the deadnames of people who changed their name prior to the point at which they became notable, and for whom a small number of reliable, marginally reliable, or unreliable media sourcing exists. Per the second paragraph GENDERID these names are not included in our articles, and is treated as a privacy interest subject to BLPPRIVACY and BLPNAME. There is a real world risk of harm to the individual and their family that would occur should we amplify the former name beyond the handful of sources that might have published it. As such, at minimum RD2 is required, and a strong consideration should be given to RD4 and OS.
• The third type is the deadnames of people who changed their name prior to the point at which they became notable, and for which no reliable sourcing exists. As with the second type, these names are not included in our articles and are treated as a privacy interest subject to the same parts of the BLP policy as previously. While there are no reliable sources for this type of deadname, there are a number of websites and discussion forums that frequently dox trans and non-binary people for harassment and harm purposes. As with the second type, there is a significant real world risk of harm to the individual and their family should we include these names, however this risk is often higher because the same doxes that include their names also typically include addresses and other personally identifiable information. As such, RD4 and OS is required.

Why is RD2 the minimum for the second type, but RD4/OS for the third? It's to do with the significantly increased risk of real world harm caused by the only sourcing being doxxing. With the second type, if you were to Google the name, you likely will only find the small number of reliable, marginally reliable, and unreliable sources. However with the third type, you are sadly more likely to find the doxxing website. My preference would be that all pre-notability deadnames for living trans or non-binary people would be subject to oversight, but reasonable minds may differ on the extent of that.

While it is true that we follow and don't lead, the agencies and bodies who regulate the sources we consider reliable are already making provisions like these, and so we are required to follow suit. To use the language of WP:NOTLEAD, this wrong is already being addressed in the real world. Many research journals are allowing for full retroactive name changes for trans and non-binary authors for papers published prior to the name change, and press organisations like IPSO, and style-guides like those from the AP recommend not including the former name unless absolutely necessary.

Mentioning the former name of a trans or non-binary person has measurable physical and mental health harm risks. There are sadly a rather loud minority of people who wish and try to inflict harm on anyone that they know or suspect to be trans or non-binary. These harms include sending death threads, swatting, and all manner of physical violence up to and including killing. Research shows that use of a trans or non-binary person's chosen name is linked to reduced depressive symptoms, suicidal ideation, and suicidal behaviour, and that even mentioning the deadname can be harmful.

Because our article histories are for the most part publicly available, by not RDing or OSing this information where appropriate, we would be removing the ability of our article subjects to actualise reveal their gender identities on their own terms, by not allowing them to control who they reveal their gender history to and when, and expose them to both stigma and harm. Because of the visibility of Wikipedia results in search engine features like the Google Knowledge Graph, we have to be extremely careful about what information we include in our articles, and what information remains accessible through the article history. Due to the Foundations resolution on the biographies of living people, we have a duty of care with regards to what we include in our articles about living people. And I would strongly argue that this extends to both the former name and gender identity history of any living or recently deceased trans or non-binary person. Sideswipe9th (talk) 01:01, 27 June 2023 (UTC) Amended Sideswipe9th (talk) 04:41, 27 June 2023 (UTC)

we would be removing the ability of our article subjects to actualise their gender identities, by not allowing them to control who they reveal their gender history to, and expose them to both stigma and harm. Respectfully, is it really Wikipedia's purpose to ensure people can "actualise" their identities? Some Lumbee people have reported that doubts about their claimed indigenous ancestry have caused emotional harm in their community, so should we have to tip toe around the fact that their identity is contested? What about people's religious identities? I tend to support BilledMammal's view; revdel the former name if it doesn't appear in available RS (as then it actually is private info), but don't revdel if it does appear in such sources. -Indy beetle (talk) 04:34, 27 June 2023 (UTC)

Whoops. I had drafted this before posting, and that sentence was following on from one I'd removed while drafting. I'll strike and amend my comment now. What I meant to say is that we would be removing the ability of our article subjects to reveal their gender identities on their own terms. In effect, we would be outing them in our article histories. Sideswipe9th (talk) 04:40, 27 June 2023 (UTC)

At first, I declined the request for revision deletion because, in my view, if there's a privacy issue, then oversight should be applied. If it's not a privacy concern, then I don't believe it falls under RD2 as I perceive it to be a simple statement of fact.

Additionally, I'm of the opinion that the Manual of Style should not act as an addition to the Biography of Living Persons (BLP) policy. The current section in question includes talk page conduct guidelines, which I believe should not be managed there. The directive "Treat the pre-notability name as a privacy interest separate from (and often more significant than) the person's current name" also seems to be beyond the purview of the Manual of Style. _→AzaToth 20:14, 27 June 2023 (UTC)

Revdel'ing should be treated and implemented the same way we do for anonymous/pseudonymous people, e.g. Catturd. If it's clear that there is harm akin to doxxing, then revdel is warranted. (I've contacted Oversight multiple times to redact the posting of catturd's private info.) SWinxy (talk) 21:25, 1 July 2023 (UTC)

I personally can’t support revdel deadname under RD2 as it is written. RD2 specifically says it is not to be used for mere factual statements, and the legal name, or former legal name, of a person, is assuredly a mere factual statement. Likewise I cannot support the argument that we must revdel because if not, we are removing the ability of our article subjects to reveal their gender identities on their own terms. Most of our content on biographies similarly removes the ability of the article subjects to reveal their history (including their personal life, including their career) on their own terms. Negative or controversial material about any living person may present a mental or emotional challenge to the subject. That does not mean we need to revdel such material. starship.paint (exalt) 06:39, 27 June 2023 (UTC)

I will always revdel deadnaming if I believe it has been added with malicious intent; we should not reward bigotry. Usually this is by drive-by IP editing anyway, so nothing of value is lost. Otherwise, I agree with you. Black Kite (talk) 07:10, 27 June 2023 (UTC)

With Black Kite's note, I fully support this sentiment. Subjects can also have criminal histories, nasty divorces, and other things in their biographies but we don't censor them because bullies may beat them over the head with it or simply because it is information which that person may wish to divulge themselves to their acquaintances on their own schedule before others would. -Indy beetle (talk) 08:05, 27 June 2023 (UTC)

I support using revdel where the information is unreliably sourced in bad faith (especially if the source is a doxxing site), or where the subject is a minor, but generally I concur with starship's view that a former name is normally a mere factual statement - an uncomfortable one for some perhaps, but we are here to build an encyclopedia. Plenty of former names turn out to have encyclopedic value after being discussed, so we should do our utmost to avoid chilling discussion. Ultimately Wikipedia is not censored, barring a small number of exceptional cases where a clear privacy interest demands action. This site thrives on open debate and transparent recordkeeping. It's important to see who said what about what and when. Interfering with the history of a page cuts deeply and is a heavy compromise. Revdel and oversight are nuclear options reserved for truly egregious cases. In terms of harm, revision history is not highly visible to the general public. Even talk pages are not well indexed or ranked on search engines. A former name buried in page history does not warrant use of these tools. Barnards.tar.gz (talk) 08:20, 27 June 2023 (UTC)

Someone equated non-notable deadnames to private information like home address, and I agree. But, I also agree with Tamzin's take, that if deadnames have been reported in RSes, it is no longer that much a private. For example, I would not want my home address on Wikipedia, but everyone knows where King Charles or President Biden lives. In my opinion, if the deadnames aren't reported in any RSes, revdel is the appropriate outcome, if it is reported by RSes, revdel is inappropriate, although inclusion or exclusion in article must be dealt with due weight. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:21, 27 June 2023 (UTC)

To be clear, I don't think Primefac's revdel was inappropriate with Levine; I just think it falls within a discretionary zone (same as there's a discretionary zone for what counts as a slur, what counts as purely disruptive, etc.). It would probably be excessive for an admin to revdel a neutrally-worded talkpage comment saying "We should include Levine's birth name, ____" [but not redacted], sourced to the Post article. It would probably be within discretion for an admin to revdel an edit to the article that uses Levine's deadname in a manner clearly intended to be abusive. On the spectrum from the former to the latter, the edit here fell a bit past the halfway point on the latter's side (inasmuch as it cited a clearly hostile opinion piece), but I see Primefac has reverted their own revdel, and I see the logic there too. So yeah. Best left to discretion IMO. One thing to remember with revdel is that whether a given edit gets revdelled is generally determined by the lowest common denominator among all the admins who look at it, so if different admins have slightly different thresholds that tends to self-correct. -- Tamzin^{[cetacean needed]} (she|they|xe) 16:45, 27 June 2023 (UTC)

I agree. Malicious intent, clear abuse, and supplementary transphobic comments may be taken into account while revdel. But, an user who adds a fact with the innocent conviction that this fact should feature in the article should generally not face revdels of their edits. Also, WP:NATIONALREVIEW has disputed reliability, so it is indeed an edge case. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:29, 28 June 2023 (UTC)

Deadnaming isn't a case for revdel. It's presumably public knowledge and should simply be reverted and everyone move on. We're putting this on a step with child pornography, libelous content, and blatant copyright violations. If "block the user" or "protect the article" are viable options, then it doesn't need revdel. Revdel is above normal admin actions and requires an extraordinary rationale, because it removes admin actions from review by the community. GMG^talk 17:18, 27 June 2023 (UTC)

Are you confusing revdel with oversight, GreenMeansGo? Revdels are usually unremarkable (often for things that are just particularly disruptive vandalism, like replacing a page with 10,000 "fuck"s), uncontroversial, and definitely not more insulated from community review than, say, page deletion. The CRD are worded pretty liberally, much more so than their sibling CSD, so there's definitely no expectation of "an extraordinary rationale"—just an adequate rationale, same as anything else. -- Tamzin^{[cetacean needed]} (she|they|xe) 18:00, 27 June 2023 (UTC)

I don't think that's true, the comparison with page deletion. Articles that are deleted after AfD retain a record of the discussion, generally preserving the review of a significant number of editors. Speedily deleted pages can usually be restored or userfied via WP:REFUND (and indeed you can usually get a copy of an AfD'd page if you explain what you want it for). Revdels on the other hand just show up with a one-line rationale in the history, offered by the deleting admin without wider review. --Trovatore (talk) 19:48, 27 June 2023 (UTC)

You're right that a revdelled edit can't be directly reviewed by non-admins, but that is no different than most speedy deletions; REFUND only covers the subset of CSD where there might be something to salvage, and that is much rarer with revdel than CSD. It's no easier or harder for a non-admin to ask "why was this revision RD3'd?" than to ask "why was this page G3'd?". If people aren't confident that admins can answer those questions honestly and self-regulate if we see abuse by colleagues, that's a much deeper problem. (I do recall one case where this didn't apply, a redirect replaced with an otherwise G5-eligible article, which I deleted via revdel under RD5. In that case, a user asked me to unrevdel and userfy, and I did so.) -- Tamzin^{[cetacean needed]} (she|they|xe) 20:28, 27 June 2023 (UTC)

It is indeed a much deeper problem, and I think most admins underestimate it. There is a divide between admins and non-admins that was never supposed to exist, and I don't know what to do about it. Jimbo's original vision was that most editors would eventually become admins; that wound up not working for the Foundation, because reasons. Anyway, we aren't going to solve that with a narrow decision on revdelling these names, but I would like it to be understood how non-transparent a revdel can look, and why I think it should be reserved for great necessity. --Trovatore (talk) 21:54, 27 June 2023 (UTC)

You call it unremarkable and I call it extraordinary, because replacing a page with "10,000 fucks" is such an egregious abuse that it doesn't need community review. I don't see CRD as being liberally worded at all: grossly insulting, purely disruptive, blatant violations, and not being able to find an OS online at the moment. It's so tightly worded that I use the same language on other projects and AFAIK, nobody's ever questioned it because it's such a high standard.

Deadnaming isn't that.

CRD specifically warns us that reverting and ignoring is the preferred method. Deadnaming is rude and inconsiderate, but it's not something that needs hidden only for admins. GMG^talk 20:18, 27 June 2023 (UTC)

I've already expressed my view on revdels for deadnaming where there's no privacy consideration (TL;DR: sometimes). I'm objecting to the word "extraordinary" because no, what I described isn't extraordinary. An extraordinary admin remedy would be something like selective page deletion, which gets brought out occasionally in IAR situations, or like indefblocking an IP address, which happens a few times a year. There were 106 (non-bot) revision deletions on enwiki on 26 June. It's a pretty routine thing. -- Tamzin^{[cetacean needed]} (she|they|xe) 20:38, 27 June 2023 (UTC)

A hundred actions isn't really that uncommon on a project this large. And...it kindof is extraordinary when the community empowers admins to work unilaterally, instead of enacting community consensus, and I'm discounting ArbCom, because I...simply don't recognize their authority. I've spent too much time on projects without ArbComs. Revert and ignore. This is the way most of this works. GMG^talk 21:45, 27 June 2023 (UTC)

I'll echo Black Kite's statements: if it's added with malicious intent, then yes, revdel. But it's not always added with malicious intent: it can happen for someone to not know it's wrong to deadname someone. LilianaUwU ^{(talk / contributions)} 18:26, 27 June 2023 (UTC)

It wasn't a revdel, but I recently had a conversation with @Acroterion: (who I did not realize was an admin and who very politely handed my ass to me) regarding deletions of names on talk pages, and, as I understand, this was their general approach.--Jerome Frank Disciple 17:47, 28 June 2023 (UTC)

@Jerome Frank Disciple: you are probably being too kind to me. It has not been my practice to revdel deadnames unless they are clearly meant to be malicious, or just plain trolling. I generally revert or redact if there is no malicious intent evident, or if it is marginal. My reading of the revdel policy as it is presently constituted appears to preclude revdel in most ordinary circumstances, and oversight in anything short of clear harassment of a BLP subject, with a name that is not a matter of public notice (notice, not record), i.e., doxxing. I haven't encountered any occasion where the latter was applied, though if accompanied by other personal information, I would support it under ordinary oversight policyAcroterion (talk) 22:18, 28 June 2023 (UTC)

Don't revdel. Revision deletion is an extreme measure at odds with the open ethos of Wikipedia, because non-admins cannot examine the change to see whether the deletion was justified. As such it must be kept for cases of extreme necessity only. This doesn't qualify. --Trovatore (talk) 19:41, 27 June 2023 (UTC)

A third policy rfc on former names in a month..... OK so this one: Hard no on making any brightline rules about revdel, and especially suppression, for people's former names - especially if we are only going to apply such a brightline rule for subject's with certain gender expressions. This also seems to have a different special problem: If someone changes John Doe to say "formerly Jane Doe" - and Jane Doe wasn't actually the former name, revert and move on -- but if "Jane Doe" is demonstrably truly the former name of the subject (and to know so we would require a reliable and verifiable source) - then we'd oversight it??? — xaosflux ^Talk 21:05, 27 June 2023 (UTC)

As far as names that have not been publicized go, the OS criteria cover incorrect doxxing as much as correct doxxing (else it would be possible to figure out which is correct based on whether it gets OS'd). I'm aware of one particular article that's been oversighted many many times over what is, as far as I can tell, an incorrect claim about the subject being trans and having a particular deadname. -- Tamzin^{[cetacean needed]} (she|they|xe) 21:54, 27 June 2023 (UTC)

This seems like even more of a mess. How would this work on an article, say it has an accepted sentance:

Character is a Youtube personality of John Doe¹

Which of these generic edit scenarios to that sentence would you want to extend suppression to?

1. ...of Jane Doe.
2. ...of Sam Doe.
3. ...of Kiyoshi Doe.

Would these scenarios only apply if the article already describes certain gender and sex characteristics of the subject? Would it only apply if there was a reference? I think that things that make sense as style guidelines don't necessarily translate in to the deletion policy. — xaosflux ^Talk 14:04, 28 June 2023 (UTC)

I would expect that any of those changes would be reverted - simply as being referenced claims, but still wouldn't think it would extend to suppression if it also included a legitimate reference. — xaosflux ^Talk 14:06, 28 June 2023 (UTC)

I don't really follow what you're saying, Xaosflux. Assertions of non-public information about living people, correct or not, get suppressed. Gender is ancillary to it. "John Doe was formerly known as Jim Doe" is just as oversightable as "John Doe was formerly known as Jane Doe," if that former name is non-public. -- Tamzin^{[cetacean needed]} (she|they|xe) 15:54, 28 June 2023 (UTC)

This discussion is about data points that are "not notable" which is a far stretch from "non-public". Information may easily be both. — xaosflux ^Talk` — xaosflux ^Talk 17:31, 28 June 2023 (UTC)

In my experience with the type of article that requires oversight, the insertion of text that John Doe had another name is typically limited to one or two names that can usually be traced via a Google search back to either an unreliable culture-war source (like Breitbart, or Daily Mail), or a doxing forum or website. Sometimes both. Whenever I request oversight for this I will typically state if the only available sourcing is a doxing forum, or a specific unreliable source.

I can give an example of such an article via email if so desired to someone with the OS permission. But per WP:BEANS I won't wikilink to it here. Sideswipe9th (talk) 18:02, 28 June 2023 (UTC)

Policy reflects practice. This discussion is putting the cart before the horse. Are there times when deadnames should be included in article space? Yes, if there are reliable sources that provide extensive coverage of it in line with existing policies. Are there times where it should be reverted and not rev del'd, also yes. Are there times where it should be rev del'd, also yes. Are there possibly times where they should be suppressed? Yet again, yes.

The problem with having so many discussions about a similar topic in such a short period is that the community can't figure out what the actual consensus is. Documented policies and guidelines, broadly speaking, document existing consensus. Policies tend to be principles based. Guidelines tend to be slightly more specific. We then apply those policies and guidelines in practice using IAR and sound judgement. Admins and users who never participated in the RfCs and other discussions that led to the policy/guideline/whatever being written are charged with enforcing and/or requesting enforcement, and their enforcement actions become a part of the growing and evolving consensus.

What does that mean in this case: it means that the concept of revdel and suppression for these is relatively new and we don't have a common practice yet. Different admins and/or oversighters will decide different things, and that is totally okay and a part of how the consensus building process works. In the case of suppression in particular, any controversial case will be discussed on the oversight list, and our discussion will provide precedent for how we address future cases based on our interpretation of the principles and guidelines laid out in the oversight policy. Those interpretations become a part of the living consensus environment that is Wikipedia's system of internal governance.

For all of the reasons above, I find this discussion counterproductive. Administrators and oversighters should exercise judgement. When something is an edge case, discuss it, either on a talk page or a noticeboard. If you think something is an edge case for suppression please email it in and then an oversighter can review it, decide that its clear cut yes/no, or decide it needs further discussion on the list. That is how our consensus on this will form. Not consistent ongoing discussions that will attract less and less people as people get worn out on the topic. If after significant time, we feel that a clear consensus has evolved, a discussion can be had at WT:BLP to update that policy. I don't personally think we've reached an on the ground consensus of practice yet, though, so it is best to let that form first. TonyBallioni (talk) 01:34, 28 June 2023 (UTC)

See, this is exactly what I was talking about with regard to the divide between admins and non-admins. Tony's position seems to be (feel free to correct if I have this wrong) that policy will result from the practice of admins, given that non-admins don't have the tools to do this (and in the case of revdels and similar, don't even have a practical way to know what the admins' criteria even are).

That effectively turns adminship into a legislative role, when it was only ever supposed to be administrative. Based on previous interactions with Tony, I am not surprised that he takes this position and don't really expect to convince him, but I do appeal to the community to reject this view. --Trovatore (talk) 01:42, 28 June 2023 (UTC)

Wikipedia doesn't have a legislature and our policies aren't laws. They're a documentation of accepted practice. Admins are a part of the community and cannot be forced to use their tools, even if a policy says that something can be done. Their decision as to whether or not to take an administrative action are inherently a part of what consensus on use of tools is i.e. if no admin is willing to do something, there obviously isn't consensus to do it. If a small minority is willing to do something that the majority won't do, their decision is going to get overturned at AN.

The non-admin part of the community does have a role to play in this as well. They can choose what to report. They can request review of items that have been revdel'd by another administrator, oversighter or the arbitration committee. If one admin declines to act, they can bring something for wider discussion at a noticeboard, where the community as a whole will discuss and either ratify or not that choice. They can report to a noticeboard first to get wider attention if it is merited. They can participate in discussions forming consensus in specific cases. They obviously have a role to play in determining the practical consensus, and I said that when I mentioned admins and other users either enforcing or requesting enforcement. My commentary was focused on the enforcing actions, however, because that is a critical part of any policy aimed at tool use, and can't be ignored.

The community absolutely can update policies and guidelines through discussion, and can review actions, but historically those only happen when there's already a well accepted consensus before having the discussion. Because of that, enforcement choice, review of them, and discussion about particular cases are the foundation of most of our policies, which are usually written after we have already decided how to act. TonyBallioni (talk) 01:56, 28 June 2023 (UTC)

Who mentioned anyone being forced to use their tools? I don't think that has come up at all. No one from the "do revdel" side is saying that any particular admin should delete such a revision, only that the revision should be deleted, which any admin could act on. I suppose it could conceivably come up if there were no admin willing to act on it even if policy said it should be deleted, but that seems an unlikely scenario. No one from the "don't revdel" side is asking for any tool use at all, at least assuming no admin acts out of policy in the first place. So "forced to use tools" strikes me as a non-sequitur.
The community updates policies and guidelines through discussion, yes. I see no reason that discussion can't happen before admins go and establish a de facto policy through (specifically admin) "usage". The discussion is how we determine consensus; it doesn't have to exist before the discussion. --Trovatore (talk) 02:10, 28 June 2023 (UTC)

I had a long reply here, but edit conflicted and lost it. The short of it is that I was explaining how you can't ignore practice as a part of policy. The community has consistently held that policy is what we do. We apparently had this same discussion 5 years ago, and neither of our views have changed. TonyBallioni (talk) 02:28, 28 June 2023 (UTC)

Yes, as I mentioned, I didn't expect to convince you. I content myself with explaining my position clearly and appealing to the rest of the community. --Trovatore (talk) 02:32, 28 June 2023 (UTC)

Deleting revisions to remove mentions of former names is still a content decision (albeit one regarding historical content), and thus it's the community's consensus that will decide in each case. Based on examining a body of specific examples, we can see what commonalities are present and the community can derive appropriate guidance. isaacl (talk) 02:19, 28 June 2023 (UTC)

How will the community do this, when they can't even see the deleted revisions? It's true, in principle you can find a friendly admin to show it to you, but how often are you going to do that, when you don't even know which deletions to have questions about? --Trovatore (talk) 02:22, 28 June 2023 (UTC)

True enough, if admins are pre-emptively deleting revisions without any accompanying discussion, then it'll be hard to know. Perhaps we need interim guidance saying that a discussion (that avoids mentioning the deadname, so the discussion itself won't be subject to later deletion) should be held prior to any revision deletion, if there is no pre-existing consensus for a given person. isaacl (talk) 02:32, 28 June 2023 (UTC)

Yes, agree here. The content part will be decided case by case as well and if there's consensus to include, that's a big part of the larger commonalities for broader guidance. TonyBallioni (talk) 02:30, 28 June 2023 (UTC)

Different admins and/or oversighters will decide different things, and that is totally okay and a part of how the consensus building process works. I strongly disagree with this; if we allow consensus to be built in circumstances where the pool of editors who can contribute to building that consensus is extremely limited then we can end up in a situation where consensus does not match the opinion of the broader community. This issue becomes stronger in circumstances like these where the community cannot even properly review the actions of those editors.

This is also against policy, which holds that the opinion of admins are granted no additional weight when determining consensus. BilledMammal (talk) 02:17, 28 June 2023 (UTC)

Exactly, BilledMammal! Couldn't have said it better. --Trovatore (talk) 02:18, 28 June 2023 (UTC)

The consensus policy explicitly lists administrative intervention as one of the ways consensus is achieved. Individual actions help determine what the policy is. It's not to say they have more weight, but choice of when and what to enforce does form a part of how we understand and apply principles and policies. TonyBallioni (talk) 02:27, 28 June 2023 (UTC)

That section talks only about admins intervening to enforce existing policy, not to form policy.

You say that it's not to say they have more weight, but if you allow admin's choices about when to intervene to form policy that is the functional effect. BilledMammal (talk) 02:36, 28 June 2023 (UTC)

If a previous name isn't verifiable from published wp:RS, per wp:ver it doesn't belong in Wikipedia anyway, without any special guideline. So the removals/exclusions under the discussed special guideline are typically about names that are published in wp:RS's. Sincerely, North8000 (talk) 18:35, 28 June 2023 (UTC)

My own perspective here aligns with GMG and especially Travatore above: this is not a context where revdel is appropriate or makes sense. It clearly does not align with the other varieties of gross disruption which revdel is meant to address and is actually counter-intuitive in this area, particularly if you want to keep deadnames out in a fashion consistent with wherever GENDERID lands after the current raft of discussions hopefully comes to some resolution. Revdel is incredibly frustrating to lower-permission editors, particularly those trying to parse the flow of previous discussion and consensus. That's why we permit it only in very narrow contexts where the potential damage to indviduals is so immediate or likely, or else situations where there is absolutely no potential legitimate editorial interest.

More to the point, this proposal would essentially make it impossible to track consensus on a matter that is certain to thus repeat itself so long as there are any number of WP:reliable sources. Not only would it make good faith repeats of the same dispute inevitable, it could give cover to tendentious parties looking to abuse process to make the claim that they were unaware an edit was against consensus even if they in fact new the details of previous edits and discussions. It would make tag-teaming an absolute nightmare and would in most cases eventually require revdelling and refactoring other user's talk page comments. That's an absolutely ludicrous approach to the situation that accomplishes nothing but chaos. This is why our private/public distinction works the way it does, and there's absolutely nothing unique to the issue of deadnames that argues for ignoring that pragmatic distinction. Mind you, I'm opposed to revdel even in the case non-RS-reported deadnames, for the reasons discussed above. But for RS-reported deadnames, the argument is, well, forgive me, but bluntly, dead on arrival. SnowRise ^{let's rap} 14:15, 29 June 2023 (UTC)

The wording at MOS:GENDERID which says that pre-notability deadnames should not be included (even if reliably sourced) as a BLPPRIVACY concern enjoys pretty wide community consensus, and given that violations of BLPNAME can be oversighted (see also: Bloody Sunday (1972); the identity of one of the perpetrators is well-known and in RSes, but has been suppressed ahead of a criminal trial), I see no reason why the lower bar of REVDEL can't be used, especially when the criteria can be read to allow it. Sceptre (talk) 12:26, 30 June 2023 (UTC)

• I have a lot to say on this topic, but for now, let me just say that one of the factors that made me opposed to extending GENDERID to dead people was this very thing. I was worried that, if GENDERID were extended, all conversation about which name the perpetrator of the 2023 Nashville school shooting is the correct one would have to be deleted or suppressed, despite this stemming from good-faith confusion. Perhaps there are some cases where this sort of thing might be appropriate, such as information being sourced to a website that brands itself on doxing people, but for cases like, say Rachel Levine? I feel that, much like the Stanley Kubrick infobox debate, if enough people clamor on the talk page that X bit of information is reliably sourced and should be included, and upon its inclusion no one complains, maybe we should reconsider what we're doing. -BRAINULATOR9 (TALK) 03:29, 1 July 2023 (UTC)
  • Agreed, it seems that if the living person wasn’t notable before transition, but every source reports deadname after transition, this still isn’t enough to report the deadname, presenting a conflict with WP:DUE. I also would not be so sure that no one complains (and I am not necessarily referring to established editors, but also IP editors and drive-by editors). starship.paint (exalt) 03:59, 1 July 2023 (UTC)

    @Starship.paint: I guess maybe I should have said "fewer people complain". -BRAINULATOR9 (TALK) 00:29, 3 July 2023 (UTC)

I do not think revdel should be allowed for this, unless the name is not given anywhere publicly available on the internet. This isn't some kind of unique privacy interest and doesn't deserve some kind of unique protection and enforcement. More generally, privacy should be the same for a former name of a transgender person under which they were not notable as it is for the former name of any other person under which they were not notable. If the subject wants to keep this former name private, that should be taken into consideration in the same manner whether or not they identify as transgender. —Lights and freedom (talk ~ contribs) 04:33, 1 July 2023 (UTC)

REVDEL can be used if it is an attack. And as you say if "the name is not given anywhere publicly available on the internet". In that case it is a privacy violation and should also be revdel'd and possibly oversighted. Existing policy already covers this, so we do not need to change wordings. But if someone wants to make an essay, that should be fine. Graeme Bartlett (talk) 22:17, 1 July 2023 (UTC)

I have to come down on the side of using REVDEL (not OVERSIGHT) for this, as a core privacy concern, by default. We wouldn't hesitate to do it for, say, someone's phone number or home address. While I think that LGBT+ activists have a strong tendency to over-state a "trans- and enby-wide" stance that deadnaming is an evil (I personally know people who are TG or NB who don't have a care at all about deadnaming, so I know from direct experience that the activist position is an overstatement), there is clearly a significant enough majority proportion of TG and NB subjects who feel it is a core privacy matter that we should default to treating it as one, unless there is evidence in a particular subject's case that argues otherwise.  — SMcCandlish ☏ ¢ 😼  23:47, 6 July 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Policy on reaction sections

Many articles covering event-related topics have sections titled "Commentary | Response | Reactions | Criticism | Opinions". These sections contain reporting of non-neutral content that's reliably sourced, often with a fact-checking element. This has led to de facto policy with two main camps, exclusionist and inclusionist. Exclusionists try to limit these sections to summaries, while inclusionists try to document all commentary that receives significant coverage. Is there any existing policy addressing these sections? I'm looking for some community input on how policy currently applies to this and how a more specific policy would look. The void century 02:53, 30 June 2023 (UTC)

I was just actually coming here to suggest we discuss how Reaction sections are quickly becoming the equivalent of "Popular Culture" sections, including any random commentary that can be sourced. There are actual legit reactions that are appropriate, such as analysis (as a reaction), or actual tangible actions to an event. But the bulk of Reactions sections are "X offered their sympathies" or similar, and that just is crappy writing that artificially extends the article. It may be fine for a new article, but these should be trimmed to actual encyclopedic info, not just because it is in the news. Masem (t) 13:40, 30 June 2023 (UTC)

Agreed. Part of it is just the natural cycle of article improvement, but I have definitely seen it get out of hand. The void century 17:39, 30 June 2023 (UTC)

It’s probably covered by WP:DUE. Barnards.tar.gz (talk) 13:50, 30 June 2023 (UTC)

I agree it's probably covered by WP:DUE, but I think editors will often argue that anything coming from a reliable source is DUE, so it might be helpful for policy to be more specific about how DUE should apply to these sections. The void century 17:38, 30 June 2023 (UTC)

Draft policy: "In sections offering reactions, analysis or commentary, due weight applies the same way. Weight should be decided based on the number of reliable sources and significance of coverage within the sources presenting the viewpoint compared to other content in the article. The status, credentials, or direct involvement of the person offering the viewpoint should not be equated with prominence of the view."

If anyone wants to help me build on this, feel free! The void century 18:28, 30 June 2023 (UTC)

This sounds like WP:CREEP if the goal is to actually promote this to a policy. This seems perfect for an essay instead. It's already assumed that editors have discretion to focus on the most salient and relevant points (reaction or not), meaning material that can be sourced but isn't relevant enough can already be removed. An essay that compared relevant reactions, borderline reactions, and clearly remove-able reactions might be more helpful. SnowFire (talk) 19:12, 3 July 2023 (UTC)

Yeah I get what you mean about creep. An essay might be a good idea. Or maybe it could be condensed to remove the second sentence so it's not just duplicating policy. The void century 20:26, 3 July 2023 (UTC)

There is an essay WP:CRITICISM: "Articles should include significant criticisms of the subject while avoiding undue weight and POV forking." I agree that existing policy probably covers the situation. DUE and WP:INDISCRIMINATE: "To provide encyclopedic value, data should be put in context with explanations referenced to independent sources... merely being true, or even verifiable, does not automatically make something suitable for inclusion.". Maybe propose adding a new bullet under INDISCRIMINATE, something like "5. A comments section..." Cuñado ☼ - Talk 19:54, 3 July 2023 (UTC)

That's a great idea, thanks! The void century 20:24, 3 July 2023 (UTC)

Draft policy: 5. A comments section. Special care is warranted when deciding whether to include commentary, reactions, criticism, analysis, responses, opinions or any subjective information from reliable sources. When reliable sources weigh in with subjective content, defer to policies like WP:NEUTRAL. The void century 17:49, 4 July 2023 (UTC)

Interesting-- I hadn't seen WP:STRUCTURE, which states Try to achieve a more neutral text by folding debates into the narrative, rather than isolating them into sections that ignore or fight against each other.. The void century 03:01, 5 July 2023 (UTC)

This helped a lot with some pages I edit. The history section needed improvement, so moved reactions and added context. Reactions that were left were about things that werent about just one event, like things that were a pattern Softlemonades (talk) 16:00, 5 July 2023 (UTC)

Agreed that adding this to the essay is a good step. I concur with the concern the OP raised, though also with WP:CREEP concerns raised in response to adjusting policy (at this point) to more directly account for "reaction" material. If it still keeps getting out of hand, we might need to revisit that. I do feel this kind of material is something of an unencyclopedic cancer, but I'm not entirely convinced it can't be resolved though other means. I would even try adjusting the MOS:TONE guideline to account for it before changing policy as such.  — SMcCandlish ☏ ¢ 😼  23:39, 6 July 2023 (UTC)

At 2021 Israel–Palestine crisis the international reactions became a lengthy list that eventually got farmed out to International reactions to the 2021 Israel–Palestine crisis. It was somewhat overdone and some of it had to go back to the main page (diplomacy and such). It's not a bad idea I think to do something like this, particularly if there a lot of reactions. Selfstudier (talk) 12:06, 7 July 2023 (UTC)

NEVENTS/GNG are too board and should be narrowed

This is stemming from AfDs on 2023 Kericho truck crash and Carberry highway collision where two relatively routine traffic collisions pass WP:GNG and WP:NEVENTS in the eyes of fellow editors. Some noted that the number of deaths makes the events notable. Others mentioned international coverage of the events. I've made the same arguments against shooting events in the USA and event reaction pages (1, 2).

I am not here to re-litigate those, but rather to point out the problem with NEVENTS/GNG on these matters. In the past, it was unusual for the BBC to cover minor events in the USA. Unlike with paper newspapers where the was limited space and every word costs money, most news outlets now is just regurgitate from other outlets with minimal thought. Their business models are no longer based on subscriptions of costly physical goods, but rather one clicks. And, of course, the "if it bleeds, it leads" adage translates into generated clicks.

Example 1 - 8 Roller Coaster Riders in Crandon, Wisconsin, Trapped Upside Down for Hours

This event was covered very widely and would satisfy GNG and NEVENT based on the standards for the AfDs linked above: NPR (USA), BBC (UK), NBC (USA), Business Insider India, CTV (Canada), The Guardian (UK), 1News (NZ), El Universal (MX).

Example 2 - Ocras Attacking Yachts

Again, we have widespread international coverage of these events that would meet GNG and NEVENTS: CNN (USA), BBC (UK), 1News (NZ), News.com.au (Australia), The Hindustan Times (India), NPR (USA), CBC (Canada), The Japan News by Yoriumi Shimbun, El Heraldo (MX)

I would like to propose that we institute more stringent criteria for new articles, especially breaking news articles. EvergreenFir (talk) 23:22, 6 July 2023 (UTC)

How exactly do those events meet the requirements of Criteria 1 of WP:NEVENTS requiring long-lasting impact beyond just routine coverage of the event itself? I feel like our notability criteria already cover this properly and people are just mis-applying them. Silverseren^C 23:26, 6 July 2023 (UTC)

In which case the guideline still clearly needs revision so it stops being routinely misapplied.  — SMcCandlish ☏ ¢ 😼  23:28, 6 July 2023 (UTC)

WP:NEVENTS squiggles its way out of this with the wording It may take weeks or months to determine whether or not an event has a lasting effect. This does not, however, mean recent events with unproven lasting effect are automatically non-notable. Even though I'm generally an inclusionist, I prefer to wait until the lasting effects have occurred. Then we can have articles about the lasting effects with wording like "the Great Orca Revolution of 2023 started with attacks on yachts in Europe^[1]" and leave it at that. Orange Suede Sofa (talk) 23:50, 6 July 2023 (UTC)

I think the guideline is not such much misapplied as ignored. Copying what I wrote in the related discussion above: Given that WP:NEVENTS and related guidelines seem to get ignored I think you would have to change WP:GNG. Maybe add a sentence to the explication of "sources". Currently the first sentence says "Sources" should be secondary sources, as those provide the most objective evidence of notability. We could insert a clarification of "secondary" directly after that: Primary news sources on their own usually do not indicate notability. -- Random person no 362478479 (talk) 01:01, 7 July 2023 (UTC)

WP:N already establishes this under WP:SUSTAINED. GNG doesn't need to be touched, as this implies that the sustained coverage applies across the board. Masem (t) 01:06, 7 July 2023 (UTC)

I don't think any of the guidelines would need to be touched if people would actually apply them. The question is how to get people to stop ignoring WP:SUSTAINED and related guidelines. One quite common issue seems to be that people argue that GNG is met based on primary news sources. One way of addressing this particular misapplication of GNG would be to make it explicit in GNG that primary news sources are not secondary sources. -- Random person no 362478479 (talk) 01:16, 7 July 2023 (UTC)

I think that is a very good idea. BilledMammal (talk) 01:22, 7 July 2023 (UTC)

The first way to get editors to apply NSUSTAINED and PERSISTENCE would be to actually mention them in relevant deletion discussions. Taking the two linked above, no editor there has mentioned either guideline point, either as a reason for deletion or to refute it as a reason for deletion. Sideswipe9th (talk) 01:22, 7 July 2023 (UTC)

I quoted NEVENTS which mentions those factors. I should have also directly mentioned NSUSTAINED and PERSISTENCE though EvergreenFir (talk) 05:02, 7 July 2023 (UTC)

I wholeheartedly agree with this. WP is awash in stuff that clearly violates WP:NOT#INDISCRIMINATE, WP:NOT#NEWS, and other policy provisions of WP:NOT. This notability guideline (not policy) is, albeit accidentally, in increasing direct conflict with policy. This is an impermissible WP:POLICYFORK, and I think we all know that the policy beats the guideline when it comes to such a conflict. However, I doubt this particular discussion is going to gain much traction. I think it would be more productive to draft specific changes, then propose them in an RfC (here, since it has wide import, but "advertised" at the guideline page, and perhaps via WP:CENT).  — SMcCandlish ☏ ¢ 😼  23:28, 6 July 2023 (UTC)

I think the solution is to properly enforce WP:NEVENTS; that may require us to reword it, but I don't think we need any changes to the underlying fundamentals at this point. BilledMammal (talk) 23:54, 6 July 2023 (UTC)

Some related (semi-)recent discussions:

Wikipedia:Village_pump_(policy)#RFC_because_we_really_need_to_relook_WP:NEVENTS Wikipedia_talk:Arguments_to_avoid_in_deletion_discussions#Adding_tragedy_and_death_count_as_a_notability_fallacy

Wikipedia_talk:Notability_(events)#Are_events_with_several_deaths_always_notable?

Wikipedia:Village_pump_(idea_lab)/Archive_49#Addressing_non-notable_event_articles:_Traffic_incidents

Wikipedia:Articles_for_deletion/2007_Alderney_UFO_sighting

-- Random person no 362478479 (talk) 00:13, 7 July 2023 (UTC)

Stronger awareness and enforcement of NEVENTS is absolutely needed. Both NEVENTS and WP:N point out that notability of events does not simply come from a burst of coverage, which is directly related to WP:NOT policies. Indeed, that's why Wikinews was created to support editors that wanted to work on these breaking events without clear notability determination. (And for that benefit, if an event becomes notable, we can copy appropriately between wikis). (I would also strongly encourage a MOS-type approach to make sure Reaction sections are not just flooding with every "thoughts and prayers"-type support from random leaders. This tends to give false appearance of notability). There are a lot of "List of X" articles that many of these types of events can be listed first and foremost before creating new articles. --Masem (t) 00:20, 7 July 2023 (UTC)

I had a brief look at the available sourcing for the truck crash and highway collision articles, and I couldn't find reliable sources newer than 5 days, and 3 weeks respectively. Because of the lack of persistent coverage, wouldn't both of those fail WP:PERSISTENCE and WP:NSUSTAINED? Sideswipe9th (talk) 00:44, 7 July 2023 (UTC)

too board

I'm sorry, I had to. (I think you meant "broad".) LilianaUwU ^{(talk / contributions)} 00:54, 7 July 2023 (UTC)

Hah! EvergreenFir (talk) 05:07, 7 July 2023 (UTC)

One of the two AfD discussions that prompted this, Wikipedia:Articles for deletion/Carberry highway collision (2nd nomination), has been closed despite all of the keep !votes being based on a brief burst of news coverage and using primary sources as evidence of GNG. The only exception to this is one citing WP:RAPID, which says that the AfD shouldn't take place until a few days after the event (which it did). The closing admin appears to have done a headcount without any further analysis. There's a serious issue of AfD regulars ignoring or actively subverting sitewide consensus. At what point do we say that "it was in the news once therefore it's notable" !votes are disruptive editing? Thebiguglyalien (talk) 22:27, 10 July 2023 (UTC)

The GNG is horribly flawed and IMHO was never intended to be the ultimate yardstick of notability. (It even has guideline in the name) My only question is can it be fixed or is it so horribly flawed it should be erased from existence? In addition to what you list:

• It is heavily biased in favor of the developed world and against underdeveloped and developing countries.
• It is heavily biased in favor of topics that have pop culture appeal and against topics that pop culture considers boring
• It is heavily biased in favor of "If it bleeds, it leads" topics and against more substantive stories that are not as extensively covered.

An example I've used previous in the context of roads is if the strict adherents of "must stick to GNG" (i.e. only what has significant, secondary coverage) get their way an article about I-95 will be an ever expanding article about accidents, collapses, hurricanes and crimes that affected the highway, plus broken and empty political promises to reubild it, with the occasional mention of serial killers who used the route to find victims. There would be little to no mention of what I-95 actually is.Dave (talk) 00:59, 7 July 2023 (UTC)

We are never going to be able to address #1; coverage in reliable sources are biased towards the developed world and thus our coverage will be biased towards the developed world. We are not here to lead social change, merely to document it and to follow.

For #2, I'm not convinced there is an issue with the level of sourcing; encyclopedic topics that don't have pop culture appeal still have sufficient coverage to write articles about them. Instead, there is an issue with the average editor being more interested in pop culture topics than non pop-culture topics (which we can't fix), and with it being easier to mass create articles on pop culture topics than on non-pop culture topics (which we can fix, by tightening SNG's and GNG - we have already taken the first steps here by tightening NSPORT).

For #3, while I agree I believe tightening enforcement of WP:NEVENT will be sufficient to address it.

Regarding your I-95 example, I think you'll find that is a WP:NOTTRIVIA problem; accidents on the I-95 will mention the road but they won't discuss the road; including them in the article is trivia and can be addressed by making it clear that we shouldn't be including trivia in articles. BilledMammal (talk) 01:20, 7 July 2023 (UTC)

Re: coverage in reliable sources are biased towards the developed world and thus our coverage will be biased towards the developed world - yes, but enwiki P&Gs can either amplify or moderate this bias, and many current trends in the editing community tend to amplify this and similar biases.

four examples

the tightening of NSPORT criteria (responding mostly to bot-like article creation) by raising the bar "equally" for the mass of athletes, has the effect of shrinking the pool of notable female athletes more than the pool of male athletes, thus amplifying bias; attempts to dilute the presumptions of notability offered by GEOLAND (also in response to bot-like article creation) by subjecting populated places in very different economic and cultural contexts to "uniform" criteria re: significant coverage, would have the predictable effect of amplifying bias by exaggerating further the gap between enwiki's coverage of rich and poor places, and between predominantly anglophone and non-anglophone ones; the deployment of strict construals of NPROF has the consistent effect of amplifying bias by ensuring consistent underrepresentation of women, people of colour, and those educated outside of major metropolitan universities, to a much greater extent than the composition of contemporary academic research itself would justify; and attempts to extend the principle of WP:AUD (developed to counteract the effects of corporate publicity strategies), beyond the major organizations and corporations it originally envisaged, have the effect of enhancing the biases that enshrine the most powerful corporations and state organizations in article space while discouraging coverage of corporations - and, increasingly, of other topics - that are most prominent in the lives of people outside of the wealthiest economies as well as coverage of non-profit and activist organizations.

I know these factors aren't especially related to the NEVENT phase of the discussion, but they illustrate the more general issue that our P&Gs (and editor interpretations of them) are not "neutral" , but rather we can choose whether to amplify or minimize various biases inherent in our sources. Newimpartial (talk) 02:05, 7 July 2023 (UTC)

Being devils advocate here. The question we have to ask is if editors want to keep these articles, is that the general consensus? If it is then our policy is wrong? Compared to the number of editors on Wikipedia, or those engaged in AFD, this talking shop is hardly participated in. We pride ourselves on consensus setting the rules but I doubt that it's the majority. To be that we really need polling tools to find the consensus.Davidstewartharvey (talk) 05:23, 7 July 2023 (UTC)

I think that is a valid point. There are certain Wikipedia editors who follow the "drama boards" (and I consider AFD to be a drama board) and certain editors who avoid them like the plague. Then there are the ones who don't even know they exist, until they are sucked into them. As such the participants are not necessarily representative of the average Wikipedian. We typically leave a notification on wikiproject talk pages, and that helps, but the average wikipedian probably doesn't follow those either. I don't know how to fix that problem. The only ideas I have would be to either auto add something like WP:Centralized discussion to everybody's watchlist or perhaps have the infobox appear on the homepage for all logged in users. But those have downsides and I'm sure would prove controversial as well. Dave (talk) 06:15, 7 July 2023 (UTC)

I think that's a valid question, but is worthy of a devil's advocate of its own. The original legitimacy claims for the notability guidelines came largely from their status as summaries of VfD precedent. I for one would happily agree to disregard these recent precedents in exchange for decertifying the notability guidelines entirely and returning to our core policies. -- Visviva (talk) 00:47, 8 July 2023 (UTC)

The apparent lack of overlap between those taking part in the discussions about notability guidelines and those taking part in AFD are a real problem here. We have a clear difference between theory and practice and to bring them back into sync we somehow need to get both groups to engage more. And don't get me wrong, I am part of that problem. As Dave said, some people avoid AFD like the plague. Personally, given the choice, I'd take the plague over AFD. At this point we don't even know whether the divergence of is a deliberate choice of people or results from different interpretations of rules. In other words, do people vote the way they do in AFD because of what they think the rules are or because of what they think the rules should be? So this discussion will definitely not be able to resolve the issue, but hopefully we can come up with some ideas of what the next steps could be. Dave has mentioned some ideas on how to draw more people's attention to the discussion. Maybe it would be an option to put up some kind of notification on AFD discussions (similar to the AFD notifications on articles that are proposed for deletion) that there is a discussion about notability rules would be a less intrusive alternative to notifying everyone in one way or another. The big downside would be that this could lead to massive selection bias in the pool of participants. -- Random person no 362478479 (talk) 18:39, 8 July 2023 (UTC)

I've tried for the last few months to clean up some of the newscruft that's built up or at least find some form of consensus on what to do with it (some of the discussions I've started about different aspects of this issue have been linked above), and I found it nearly impossible. There are several issues surrounding event notability, but here are a few of the most prominent ones that I've noticed:

1. Editors are interpreting WP:SUSTAINED to mean that anything that was reported in the news over multiple days is notable. For example, if a random crime occurs on Monday, and then the guy is arrested on Wednesday, that's often described as sustained coverage. This is opposed to the spirit of the guideline, which is that notable events should still be studied and covered well after no further developments take place to demonstrate that it's not a "brief burst of coverage".
2. Similarly, editors are using breaking news and updates to satisfy GNG even though these are primary sources. In the previous example, neither reporting on the crime nor reporting on the arrest can reasonably contribute to GNG. Otherwise everything that ever happened and was published in a newspaper would be notable. For GNG to be met, we need to see retrospective analysis after the event has concluded. This might be books about the event, scientific journals analyzing the event, or long form retrospectives published in newspapers some time later.
3. Editors are incentivized to be the first one to create an event article as soon as it breaks in the news, resulting in WP:TOOSOON creations that usually end up not being notable. We have WP:DELAY discouraging this, but it's clearly not working. It doesn't help that WP:RAPID is found right below it and is often cited even after it's apparent that notability has not developed. This problem is exacerbated by WP:ITN, where creating an article for every minor event is expected and the internal community that's developed at ITN actively discourages consideration of notability in favor of its own subjective evaluation.
4. There are several article creators and AfD regulars that have come up with this idea that "death count" is somehow a valid claim to notability, and any time in history where at least 5-10 people died should have an article.

I think that the first step is that these things need to be rejected much more firmly in AfD, both by participants and by closing admins. I would go as far as to say that the latter issue—repeatedly citing death count after being told that it's not mentioned anywhere in the notability guidelines—is disruptive editing. Beyond that, modifications to NEVENTS or even GNG may be helpful, but we would need a solid wording reflecting consensus. Thebiguglyalien (talk) 01:22, 8 July 2023 (UTC)

I'll also list a few AfD discussions I've been involved in where this has been an issue. I believe that many of the !voters and the closers in these discussions demonstrated that they have no interest in considering notability guidelines. Multiple !voters chastised me for referring to news coverage as a primary source.

• Wikipedia:Articles for deletion/Kasganj level crossing disaster
• Wikipedia:Articles for deletion/2008 M6 motorway crash
• Wikipedia:Articles for deletion/2023 Farmington, New Mexico shooting
• Wikipedia:Articles for deletion/2023 Dadeville shooting

That last one got me two hateful messages on my talk page and I was taken to ANI, purely for the fact that I nominated it. It still has no sigcov outside of breaking news. Thebiguglyalien (talk) 01:34, 8 July 2023 (UTC)

Possible technical assistance with determining notability

The issue of multiple news outlets mechanically redistributing the same news item, as noted above by EvergreenFir, is a real one and has other consequences outside of Wikipedia. As a result, there has been some research into how one may identify if the same news item from a single source is spreading throughout global media and giving it undue weight. One example of this research is here, and I am aware of other projects as well. Perhaps in the long term, our brave toolmakers can take a stab at creating some assistance to help tackle this issue in the future. Orange Suede Sofa (talk) 00:34, 7 July 2023 (UTC)

Finalised changes to GEOLAND now ready for comment

Please see here for the finalised change to our notability guide for populated places, administrative areas, and disputed areas: Wikipedia talk:Notability (geographic features)#Finalize proposed change.

Given the length of this discussion, and the number of editors already involved, this change may be made WP:BOLDly. FOARP (talk) 07:55, 17 July 2023 (UTC)

14 July Community Call

Edit Check protoype (mobile)

Hi y'all – as people interested in Wikipedia policies and how they are applied, the Editing Team thought some of you might be interested in participating in the virtual meeting we're hosting this Friday, 14 July (15:30 to 17:00 UTC).

We'll use this time to discuss Edit Check, a new project that will present people with policy-related guidance while they're editing.

The first "check" we're building prompts people to add a reference when they don't think to do so themselves.

Regardless of whether you're able to make the meeting or not, we would value learning what you all think of the Edit Check prototype.

If the above brings any questions to your mind, please ping me so that I can try to answer them.

In the meantime, this MediaWiki page should contain all the information you need to join Friday's conversation.

Note: if there is another/more effective place(s) to post invites of this sort, please let me know 🙏🏼. PPelberg (WMF) (talk) 22:05, 11 July 2023 (UTC)

There were three signups for this meeting. Is that the actual amount of people that showed up as well ? Just curious. —TheDJ (talk • contribs) 13:24, 18 July 2023 (UTC)

A way to edit Wikipedia in censored places (free to test)

The TCPioneer tool offers direct access to Wikipedia in China without being blocked. However, it is still unknown if it is useful in other censored places.
WM:OP/H says that Tor is one of the few ways to edit Wikipedia in China. I don't believe that the administrators have seriously considered this problem. Downloading Tor is very slow and sometimes impossible in China. After accessing WIkipedia by Tor, unregistered users are still blocked and require an IP block exempt, but it is impossible for them. This means that unregistered users in censored areas must find ways to directly access by themselves. I found this tool on Chinese Wikipedia's help page.
So isn't it a serious problem that our proxy blocks have blocked lots of people living in censored places but willing to contribute from editing, but we haven't given them a reasonable solution? IntegerSequences (talk | contribs) 03:35, 19 July 2023 (UTC)

I don't think Wikipedia should formally endorse or encourage any method of circumventing national laws. I'd certainly prefer to have more editors from other parts of the world building enwiki and other language Wikipedias, but editors need to be aware that contributing to Wikipedia in an authoritarian country comes with real world risks. Thebiguglyalien (talk) 15:36, 19 July 2023 (UTC)

@Thebiguglyalien: I don't think Wikipedia should formally endorse or encourage any method of circumventing national laws. I somewhat disagree, simply based on the existence of WP:TOR, which openly provides advice to editors in China who are barred by the Great Firewall of China.

On another note, if you review the article on censorship of Wikipedia, specifically within China, you'll see that Jimbo Wales has been frequently lobbying to get Wikipedia unblocked in China and has even suggested that any one government can control the flow of information of what people know in their territory will become completely antiquated and no longer possible.. The Foundation might not be openly challenging China's authority, but they certainly aren't turning a blind eye to blatant censorship. Cheers, ⛵ WaltClipper -(talk) 17:58, 19 July 2023 (UTC)

I would not trust any system for circumventing government surveillance to be foolproof. At least some of the editors using that tool will be agents of the Chinese government, who likely will be trying to compromise the tool. I say this knowing nothing about the origin of the tool, but there is even the possibility that the tool is a honeypot. Some may think I'm being overly paranoid, but my FBI file from my graduate school days is over 200 pages long, even though I never did anything more than a possible misdemeanor. Donald Albury 18:00, 19 July 2023 (UTC)

Wikipedia should not promote or endorse anything that can put people at risk. Especially not if Wikipedia has no way of vetting it or its providers thoroughly. -- Random person no 362478479 (talk) 18:27, 19 July 2023 (UTC)

That help page is quite old, and isn't well maintained. Tor is certainly one option in China, which is I think what that page says. To paraphrase someone else on block exemption, it's given out like candy to users in China. And then I'd add a few other countries to that list. So the real problem is having a system where people can proxy through other IP addresses, whilst preventing vandals and trolls editing through those same IP addresses. I'm not familiar with TCPioneer, so I can't comment on that, but to date a solution that can only be used by good users in China has been hard to come by. -- zzuuzz ^(talk) 18:15, 19 July 2023 (UTC)

The TCPioneer tool offers direct access to Wikipedia in China without being blocked. You have to trust the person making and distributing however, cause that person might just be the Chinese state. You have no real way of knowing for sure they are not.

So isn't it a serious problem that our proxy blocks have blocked lots of people living in censored places but willing to contribute from editing, but we haven't given them a reasonable solution? Sure, but it's an imperfect world so it is what it is. —TheDJ (talk • contribs) 19:40, 19 July 2023 (UTC)

NJOURNALS essay under discussion

I invite those interested in academic journals on Wikipedia to participate in discussion at WT:NJOURNALS. I have a particular edit I am championing in this section, but there are other discussions there which would benefit from outside perspectives.

jps (talk) 16:32, 21 July 2023 (UTC)

AFD discussion touching on a VPP RFC

A discussion has been opened regarding the deletion of 82 airline destination-list articles that can be seen here: Wikipedia:Articles for deletion/List of Air Midwest destinations FOARP (talk) 14:22, 25 July 2023 (UTC)

RfC on MOS:SECTIONCAPS after a colon

Should MOS:SECTIONCAPS recommend that, in a heading, the first letter after a colon is capitalized?

That is, should this example be reversed?

Use: 1891–1940: early history
Avoid: 1891–1940: Early history

Similar past discussions: May 2023, October 2022, March 2022. Wracking ^talk! 05:43, 9 June 2023 (UTC)

• Yes. Nobody follows this guidance, on or off Wikipedia. On Wikipedia, most people already capitalize after the colon. (85% of articles, by my count.) The Chicago Manual of Style and APA style recommend capitalizing after a colon in a heading (yes, even in sentence case). Wracking ^talk! 05:45, 9 June 2023 (UTC)
  • Remove the example/don't specify. Thanks all, for your thoughtful comments. I agree. We really didn't need this example in the first place per WP:CREEP. Wracking ^talk! 18:36, 10 June 2023 (UTC)
• Yes. AP Stylebook as well: Capitalize only the first word and proper nouns in headlines that use AP style. Exception: The first word after a colon is always uppercase in headlines. Hyphenation Expert (talk) 08:02, 9 June 2023 (UTC)
  • Remove, capitals used as is consistent with the page's variant of English Hyphenation Expert (talk) 09:49, 9 June 2023 (UTC)

    The idea that variants of English come with capitalization styles is novel to me. Did you just invent that, or does it come from somewhere? Dicklyon (talk) 16:40, 11 June 2023 (UTC)

    Yeah, I've read nearly every style guide published since the late 19th century, and I've never seen any evidence for such an idea.  — SMcCandlish ☏ ¢ 😼  02:43, 14 June 2023 (UTC)

    UK: don't capitalise.

    The Guardian When a colon is used in a headline, the next word is usually lowercase, eg Osborne: there is no plan B.

    Cambridge Use sentence case for headings and headlines (and also remember to use lower case after a colon)

    Oxford Headlines, journal articles, chapter titles and lecture titles: Only capitalise the first word... ‘Multiplicity of data in trial reports and the reliability of meta-analyses: empirical study’

    ICL Sentence case should be used for headlines and the titles of articles, chapters and lectures... ‘The impact of sleep and hypoxia on the brain: potential mechanisms for the effects of obstructive sleep apnea’ Hyphenation Expert (talk) 01:16, 18 June 2023 (UTC)

    Zero of them say this is a feature of British English, and you can find American style guides that also prefer this capitalization habit. You are mistaking the cross-pollinating habits of a handful of publishers in Britain with an inherent feature of the language of Britian. It's a common error, but still an error.  — SMcCandlish ☏ ¢ 😼  20:35, 18 June 2023 (UTC)

• Don't specify. We don't need a rule about this and we certainly don't need to follow what some American style guides do.—S Marshall T/C 08:45, 9 June 2023 (UTC)

Agreed. No one's reading speed or comprehension is going to be affected by a single capital letter. This specification provides absolutely no benefit to readers and belongs to the WP:CREEP territory. Carpimaps ^{talk to me!} 16:10, 9 June 2023 (UTC)

• US usage varies. The guideline is fine as it is. Tony (talk) 11:49, 9 June 2023 (UTC)
• Treat it as just another WP:STYLEVAR issue. Either is fine, in case of dispute retain whichever variant was first used. 74.73.224.126 (talk) 22:03, 9 June 2023 (UTC)

  For sake of clarity, prefer remove/don't specify though if some people really want to explicitly note that both are fine, I won't stand in the way. 74.73.224.126 (talk) 22:20, 10 July 2023 (UTC)

• Australian government style manual: After a colon, capitalise the first word of questions that are complete sentences. This makes it clear that the question mark applies only to the text after the colon. [1] Hawkeye7 (discuss) 00:40, 10 June 2023 (UTC)

  I wouldn't cite the "Snookbook": it's crappy. Tony (talk) 01:20, 10 June 2023 (UTC)

  There's no such thing as a crappy style guide. Language is whatever people want it to be. The better question is if the style guide unpopular? That's the real issue... I would agree an unimportant, unused style guide's opinion doesn't matter. (but Chicago Manual of Style, regardless of an Australian guide, is pretty damn important regardless.) SnowFire (talk) 17:23, 10 June 2023 (UTC)

  capitalise the first word of questions — Not applicable here, because MOS:SECTIONSTYLE says that "section headings should ... Not be phrased as a question". Mitch Ames (talk) 13:10, 10 June 2023 (UTC)

• No change (the existing "use lower case, avoid capitalisation" is correct). According to Colon_(punctuation)#Use_of_capitals, with my emphasis here, "American English permits capitalisation" but does not require it. Wikipedia's MOS:CAPS says "avoid unnecessary capitalization", use sentence case (and a colon does not start a new sentence) and we should be consistent — Preceding unsigned comment added by Mitch Ames (talk • contribs)
• Remove guidance. Initial capitals following colons are standard, as a quick browse of many published books or Internet sites shows. Wikipedia should follow actual usage, and besides, plenty of perfectly valid style guides explicitly recommend the usage. I'd personally be inclined to reverse the guidance and mandate capitals, but per WP:CREEP, just let the main editor of an article use a consistent style, regardless of what it is. People who prefer the lowercase can be happy that way, just let others use the valid, common, and style-guide approved capital. SnowFire (talk) 17:23, 10 June 2023 (UTC)
• No change for the following reasons:
  1. The existing guidance is marginally simpler (no need to carve out an exception to sentence case for word after colons).
  2. There’s no need to comply with any particular 3rd party style guide - Wikipedia defines its own style and doesn’t need to stick to sources in this respect, unlike for article content. This is not to say we should completely ignore best practice in sources, but they are a weak influence. There’s every chance that we are the experts for our use case and will come up with better guidance than any external style guide.
  3. Change may prompt a flurry of rather pointless edits to achieve “compliance”.
  4. There does seem to be some (very) slight advantage to the existing guidance: Linking is easier if titles are in sentence case. It is easier for articles to be merged or split if headings resemble titles.
  5. There’s so little difference either way that my second choice after no change would be to remove the guidance completely and leave it to local consensus. Barnards.tar.gz (talk) 18:38, 10 June 2023 (UTC)
• Remove guidance , unnecessary rules creep with no demonstrated strong advantage. It is also good to remove rules in the MoS that go against common usage and real world style manuals. —Kusma (talk) 18:43, 10 June 2023 (UTC)
• Remove. No need to have MOS guidance on post-colon capitalisation if nobody follows it anyway. Can be revised if situation changes. Alpha3031 (t • c) 03:50, 11 June 2023 (UTC)
• Do specify - There have been several suggestions to ""remove guidance", but I propose that we should have an example or explicit guidance in any case: either a specific example, or an explicit statement that either is acceptable (so MOS:STYLEVAR applies). The reason:
  1. MOS:CAPS and MOS:SECTIONCAPS already say "sentence case", and - in the absence of any other specific guideline - from that one can reasonably deduce that lowercase "1891–1940: early history" is both correct and mandatory. (The text following a colon is not a new sentence.)
  2. Multiple other style guides say "capitalise" and that is (apparently) common practice already on Wikipedia and elsewhere.

If we don't explicitly specify one, or explicitly state that either is acceptable, we run the risk of ongoing disagreement between those who assert that lower case is implicitly required by MOS:CAPS, MOS:SECTIONCAPS (and they could legitimately uncapitalise existing instances because STYLEVAR does not apply, because CAPS, SECTIONCAPS is clear), and those who assert that capitalisation is OK, or even necessary (because of common practice). Mitch Ames (talk) 06:32, 11 June 2023 (UTC)

STYLEVAR applies whenever there is no specific guidance; it would be neither practical nor desirable to list out every single case where it applies, even if occasionally we do so because some specific point has become particularly contentious. 74.73.224.126 (talk) 21:28, 12 June 2023 (UTC)

• Such a change would violate the sentence case we've had for two decades on WP. Tony (talk) 07:11, 11 June 2023 (UTC)
  • Yes, it would change an old rule. But it would change an old rule that most people already don't follow. Wracking ^talk! 17:54, 11 June 2023 (UTC)
    • Most people don't follow any of the capitalization rules. They create new articles with title-case titles, and populate them with title-case headings, and capitalize what's important to them. Those things get noticed and fixed by gnomes like me. I hadn't done much on this particular pattern yet, but I might try taking it on (the trouble is that the thing after the colon in the heading has to be looked at carefully, case-by-case, to see if it's a proper name or not, so this will be slow). Dicklyon (talk) 23:24, 11 June 2023 (UTC)
      • I provided a source when I said "most people do X", so I'd ask that you do the same. :] Capitalizing after a colon while maintaining sentence case is not the same as unexperienced users improperly using title case. My guess would be that most gnomes don't notice this "issue" because they don't know the rule exists—and they don't know the rule exists because it's unintuitive (going against other prominent style guides). And if they do know the issue exists, I think they don't want to devote their time to its (as you noted) tedious mending. Wracking ^talk! 01:46, 13 June 2023 (UTC)
    • @SchreiberBike: for example fixed the ": Early years" to ": early years" at Charlie Chaplin in 2021. Nobody gave it a mention or touched it since. Dicklyon (talk) 23:44, 11 June 2023 (UTC)
• No The proposal is to mandate capitalisation after a colon in section headings. While some styles guides might advocate this, it is far from being consistent and one must also consider whether such guides would advocate sentence case or title case for section titles. MOS:COLON specifically deprecates capitalisation after a colon with few exceptions, of which this would not be such a case. Removing the guidance at MOS:SECTIONCAPS would create an inconsistency with the superior guidance and with the overarching principle at MOS:CAPS to avoid unnecessary caps. It is not shown that the proposal falls to a case of necessary caps. I am seeing no cogent (evidence based) arguments to change the existing guidance and sound reasons to retain. Cinderella157 (talk) 10:32, 11 June 2023 (UTC)
  • For clarification, the guidance I cited is specifically for sentence-case display text such as titles and headings, not body-text sentences. Wracking ^talk! 17:54, 11 June 2023 (UTC)
    • My first sentence makes it quite clear that I have understood the proposal. The rationale I give is that the proposal would be inconsistent with superior guidance, which applies generally and not specifically to just body text. Cinderella157 (talk) 23:12, 11 June 2023 (UTC)
      • Sorry for misunderstanding you, thanks for explaining. This was a point of confusion in the past. Wracking ^talk! 01:46, 13 June 2023 (UTC)
• No, leave it – There are many different reasons for why people do not always follow the guidance, e.g. to use sentence case in headings, but mostly it's just that they aren't aware. Having this guidance as a reminder for a common error case is useful, and guides that who want to move toward consistency. It's not clear what kind of simple rule could replace what we have and expect more people to do the right thing; sentence case except after color is just arbitrary and awkward, and inconsistent with out general guidance of avoiding unnecessary capitalization. Dicklyon (talk) 23:20, 11 June 2023 (UTC)
• Comment - I'd recommend no changes be made in any pages, concerning this uppercase/lowercase topic. Until this RFC's decision is rendered. GoodDay (talk) 00:04, 12 June 2023 (UTC)

  Was that comment in reaction to the edits I made shortly before? I fixed case after years with colons in 3 high-profile articles, not just because the guideline says to, but also to test the waters and see if any of the many editors of those articles notice or care; you can look at my contribs it you want to see which, but please do not revert to the un-preferred state. Dicklyon (talk) 15:28, 12 June 2023 (UTC)

  I went ahead and fixed another dozen or more prominent articles with "Early years" after colon, including about a hundred other headings with caps after color, and also a few dozen with fully over-capitalizaed "Early Years" after color. Pretty much no reaction, except one editor who reverted a few and then read the guideline and self-reverted. This little test seems to make it clear that editors generally don't mind the WP style of avoiding unnecessary capitalization, and that they're often just not aware, and that moving in the direction suggested by guidelines is a good way to make things more consistent. Dicklyon (talk) 23:11, 17 June 2023 (UTC)

  @Namdor67: OK, I finally provoked a notice and revert here, by a 5-weeks-new editor, with edit-summary argument Case is correct. Refer to any footballer with section titles, Messi, Ronaldo,Trent Alexander-Arnold and so on... Now, I'm pretty sure this is not really a styling question about footballers, nor about sports, but this kind of domain-specific over-capitalization is pretty well known to us, having been discussed extensively recently at WT:MOSCAPS. — Preceding unsigned comment added by Dicklyon (talk • contribs) 21:33, 20 June 2023 (UTC)

  I did another hundred or so, to see if there's any signficant objection to lowercase from watchers. I got just one more revert, from a one-edit IP. It seems clear that editors/readers are broadly OK with following the usual WP guidance of avoiding unnecessary capitalization, even though they often don't know and tend to cap as if these were subtitles. The guidance should help, at least for those who look for guidance. Dicklyon (talk) 22:19, 13 July 2023 (UTC)

• No change: continue in sentence case for consistency with treatment of colons within the text. Certes (talk) 19:53, 12 June 2023 (UTC)
• Remove guidance. As long as articles are internally consistent that's all that matters for something so completely trivial as this. Thryduulf (talk) 23:16, 12 June 2023 (UTC)
• No change. I've thought about this (see original WT:MOSCAPS thread), and the reason that some other style guides do this is they are treating each element as a "title" and giving it sentence case independently. WP even does this (usually) with sentence-case citations of articles with a title and a subtitle (|title=Mammal barbering: Proper procedure for shaving weasels). However, WP headings are headings, they are not article titles; "Colour: palettes and meaning" looks kind of ridiculous as "Colour: Palettes and meaning", and makes the reader wonder why "Palettes" is capitalized. "Is it a proper name? Is this some kind of emphasis?" Capitalizing after a colon is fussy as well as potentially confusing, half of editors won't do it, and changing to that style would involve a tremendous number of twiddly edits to probably a hundred thousand+ pages (WP:MEATBOT?). I agree with Dicklyon above that current advice is consistent with MoS's general avoidance of capitalization that is not necessary. I am quite certain we should keep a rule on this, as just the heat in this discussion makes it clear that certain individuals feel very strongly about this, which means people will editwar about it if there is no rule. MoS's two purposes are presenting consistent content to readers, and forestalling (or at least quickly ending) repetitive "style fights" among editors.  — SMcCandlish ☏ ¢ 😼  02:24, 14 June 2023 (UTC)

  STYLEVAR is a thing. We don't need MOSBLOAT; if people start to editwar, whichever style was used first controls. 74.73.224.126 (talk) 14:11, 14 June 2023 (UTC)

  The very fact that this RfC is an ongoing heated fight about the matter (and not the first one) is a clear indication that we do need a specific rule on it, even if it's rather arbitrary..  — SMcCandlish ☏ ¢ 😼  20:37, 18 June 2023 (UTC)

• Remove guidance - No reason for having a guidance that everyone ignores and that goes against standard style guides. : Alexcs114 :) 16:12, 17 June 2023 (UTC)

  So the cited style guides that are like ours and suggest lowercase are not "standard"? Or you just didn't notice that such guidance, matching ours, is not uncommon in style guides? See refs and above.Dicklyon (talk) 21:35, 20 June 2023 (UTC)

• Allow both as acceptable MOS:STYLEVAR. Between removing the guidance and explicitly noting that both examples are valid, I agree with Mitch Ames that we should explicitly say so, given that it has been the subject of significant discussion. But 74.73.224.126 is of course also correct that removing the guidance would mean MOS:STYLEVAR applies no less. Adumbrativus (talk) 06:00, 23 June 2023 (UTC)
• Keep or remove the guidance; don't reverse it. Is 1891–1940: early history a special case because early is the first word of the title, preceded only by numbers? Would we treat Invention: early history differently? Certes (talk) 10:01, 11 July 2023 (UTC)
• Don't specify: unneeded, finicky micromanaging from the Manual of Style is not really what we need. Edward-Woodrow :) _[talk] 13:01, 12 July 2023 (UTC)
• Why? The purpose of the Manual of Style is to make sure that articles don't look too different from each other and to stop editors bickering one another. Some rules are best left for the editors to implicitly decide, and if they start arguing about choosing one over the other then my concern would be about the editors themselves. CactiStaccingCrane (talk) 17:22, 12 July 2023 (UTC)
• Remove/don't specify. Clearly doesn't represent a consensus of editors, so we should not treat this as a guideline, but there's no need to explicitly provide the opposite right now. —siroχo 22:44, 13 July 2023 (UTC)
• Remove guidance 1891–1940: early history is not sentence case as the clause following the colon is a new sentence that should have the first letter capitalized. Keeping goes against prominent style guides as well as the common understanding of most Wikipedia editors. :3 F4U (they/it) 03:08, 15 July 2023 (UTC)

  What's after the colon is seldom a clause or a sentence; typically just a noun phrase. But even if it was a clause, we don't cap after a colon in sentences. Dicklyon (talk) 04:55, 15 July 2023 (UTC)

• Remove guidance and treat this like Oxford comma, en- versus em-dash, etc. As long as the article is internally consistent, that's all that matters. -- Tamzin^{[cetacean needed]} (she|they|xe) 05:03, 15 July 2023 (UTC)
• Remove guidance and allow both. Both the status quo and the proposed change strike me as unnecessary. The capitalization of one letter is not going to make a difference in the vast majority of cases; e.g., both "1891–1940: early history" and "1891–1940: Early history" are semantically the same. I would be much more concerned about the lack of consistency within the same article. Epicgenius (talk) 18:00, 21 July 2023 (UTC)
• Remove guidance as textbook instruction creep. – Teratix ₵ 23:56, 22 July 2023 (UTC)
• No change. As it is, there is both a general rule ("Wikipedia avoids unnecessary capitalization") and the specific rule supporting the current guidance. Removing the specific rule is unlikely to end the myriad discussions about this issue. If advocates of capitalization after a colon would like to replace the current specific rule, I would much prefer that over just removing the rule. Something like "Capital and lowercase are both acceptable when following a colon in headings, as long as usage in the article is consistent" would be distasteful to me, but it would still save a lot of time. Either that, or the current version, would easily pass the bar of WP:NOTCREEP: "succinctly states community consensus regarding a significant point"—unless you take the view that capitalization issues are insignificant, in which case it'd be more transparent to just go with "abolish MOS:CAPS". Firefangledfeathers (talk / contribs) 01:11, 23 July 2023 (UTC)

  Just to be clear (you're probably being facetious): if the community considered capitalization matters insiginificant, it would not collectively devote so much time and energy to debating them.  — SMcCandlish ☏ ¢ 😼  22:09, 24 July 2023 (UTC)

• Comment I didn't even know this capitalization after a colon was even a possible style rule. (Maybe I missed that day in my college career?) Learned something new today. -- llywrch (talk) 20:35, 25 July 2023 (UTC)

References

Informing editors of WMF research

I was recently made aware of Wikimedia Research in connection to a discussion about WP:SIZE. What kind of resources to we have here on English Wikipedia to connect editors to the research coming out of WMF and other teams focused specifically on Wikipedia? Peter ^Isotalo 16:59, 20 July 2023 (UTC)

@Peter Isotalo is there some sort of specicic policy proposal or question you have? The site you linked to already has much information on that process. — xaosflux ^Talk 14:08, 24 July 2023 (UTC)

@Xaosflux, I'm not looking for the research itself, I'm looking for any sign of activity of us, the editing community, trying to keep up to date with current research. For example, to help us figure out how to write guidelines on how to write articles. Peter ^Isotalo 19:33, 24 July 2023 (UTC)

If you (or others) are interested in this, then you might want to subscribe to the m:Research:Newsletter. It also appears as a regular feature in Wikipedia:Wikipedia Signpost. WhatamIdoing (talk) 00:53, 25 July 2023 (UTC)

I think if you start reading up on research "to help us figure out how to write guidelines on [or?] how to write articles" you are in for a long and largely fruitless effort. Very little of it indeed is directed at that sort of thing. Wikipedia talk:WikiProject Women in Red has had some good (and long) discussions on research relevant to it (most recently this, soon to be archived), but I can't remember seeing other projects having similar discussions. Johnbod (talk) 01:09, 25 July 2023 (UTC)

@John, discussions like the one you linked to are kinda what I'm interested in. Do you know of any other discussions directly related to a published research article? Peter ^Isotalo 07:30, 25 July 2023 (UTC)

Several of these were discussed at the time. I think Tripodi's first paper had an especially long section a couple of years ago. User:Ipigott might be the best person to ask. Johnbod (talk) 14:42, 25 July 2023 (UTC)

I think some discussions turn up at the village pumps or other relevant discussion pages, but I'd echo Johnbod about the possibility that it will be fruitless. We sometimes don't want to believe the evidence, especially if believing it would mean that we should be doing something else. This means that if you find some research paper that says, say, "Nearly everything written about physics in the English Wikipedia is soooooo overly complicated that almost nobody can understand what the article is about, even if you have a masters degree in that exact subject", then someone will say, "Look, guys, researchers say we aren't complying with our own guideline about Wikipedia:Make technical articles understandable" and another editor will show up to say "How dare those ignorant non-editors (← that's an insult) express an opinion on whether my beautiful article has any flaws! If they only knew what I suffer through, to keep people from using inaccurate and vague oversimplifications, like atomic particle instead of properly labeling them as fermions and bosons".

A few simple examples:

• Almost no readers actually read the sources, but we have editors who insist that we are adding sources to articles primarily for the sake of readers. (Sources are very useful to us as editors.)
• Almost no readers actually read past the lead, but the pinnacle of achievement is an article of several thousands of words.
• Every survey of readers says they want more pictures/multimedia, but most articles still have 0 or 1 pictures in them.
• Every report on reading says that people have an easier time reading the article if the lines of text aren't too wide and there are pictures and other elements to help "anchor" which part of the page you're on, but most articles are still an oblong gray blur, and we were very upset about the change to the width earlier this year.
• We have no reports – zero, ever – of readers being upset that Wikipedia had a simple, factual article about a business (e.g., "Bob's Business, Inc. is a widget manufacturer in Whoville. It's known for making blue-green widgets and once won a minor award", with an official link to the business's website) or similar subject they were searching for at Google, and yet some editors try to remove as many of these articles as we can because we know they're WP:NOT appropriate for Wikipedia and are just being used for spam and marketing and other forms of evil. No reader ever thinks "How terrible of them. How disgustingly low class and unencyclopedic for Wikipedia to actually have some information about this slightly obscure subject that I was trying to learn more about." It's only (some) editors who say "If we have an article about this subject, it will hurt our reputation."

I get it; some subjects are the victims of self-promotion. Sometimes people create articles that aren't viable because there are no independent sources, and an article based on a person or business praising itself is not NPOV. I've had a note to myself to sort out the changes to this article, which is about a business that builds portable shelters for use after natural disasters and for safer homeless camps. I suspect that the changes involve some marketing bafflegab (by our extremely unusual standards), but there might be some useful and appropriate factual changes in there, so I don't want to overreact. But I want you to imagine someone searching for this small(er) company. Would they be better off coming to Wikipedia and finding an article here, even if it has a bit of marketing bafflegab in it, or coming to Wikipedia and finding nothing? Or not coming to Wikipedia at all? WhatamIdoing (talk) 18:27, 25 July 2023 (UTC)

All that is true, but what I really meant is that it is not the purpose or intention of most academic research into WP to "help us figure out how to write guidelines on how to write articles". Except for the common calls to "write more articles on women, dudes!", which rarely show any awareness of the effects of us covering all of history, or that by far our largest bio category is professional sportspeople, much academic research tries to extract meaningful conclusions from quantifying and analysing some very minute fraction of edits here, meeting certain conditions. The paper mentioned in the link above is an example. Academics have trained themselves in fancy mathmatical techniques for analysing big data, and want to apply their skills to the hot topic of social media, but guess what, boring old Wikipedia is the only big site that lets them get their hands on their big data. Johnbod (talk) 04:08, 26 July 2023 (UTC)

For medical articles, most of the papers I've seen are trying to figure out whether the articles in a given subspecialty are accurate (the alternative being "please panic now, because we have long since proven beyond any doubt that physicians and other healthcare providers use Wikipedia articles for work" – I believe that was a major source of motivation for Doc James to start editing), with "accuracy" usually defined as "matches the content in a popular textbook".

I don't pay enough attention to the broader Wikipedia-oriented research to know what's the popular subjects at the moment. I'm sure that HaeB would know. WhatamIdoing (talk) 17:07, 26 July 2023 (UTC)

I agree there's a problem with making WMF research relevant to us in the editing community and I can totally understand the annoyance regarding researchers making very obvious errors in published articles. But I don't share your grognardy grumpiness here. I think there might be some real gems in research regarding reader behavior and technical aspects, like what's been up for discussion here regarding article size.

To start with, I'm mostly trying to get a sense of how we in the editing community perceive and interact with research results. Peter ^Isotalo 09:00, 27 July 2023 (UTC)